Web Griffin Badge Of Honor

Setting Up Badge of Honor on Your Site

Badge of Honor is a browser extension and JavaScript widget that lets you display social proof badges — things like GitHub stars, LinkedIn connections, Twitter followers, Stack Overflow reputation — directly on your website or portfolio. It's by Web Griffin, same team behind several other dev-oriented tools. The setup is straightforward enough that most people get it working in under ten minutes, but there are a few gotchas that will bite you if you're not paying attention. I ran into this when trying to add GitHub star counts to a client's documentation site. The standard embed code worked fine locally, but on the production server behind a strict Content Security Policy, the badge requests were being blocked. The error was silent — the badge just didn't render. What I ended up doing was adding https://badgeofhonor.com and all its subdomains to the CSP connect-src directive, along with the API endpoints for each platform I wanted to pull from (api.github.com, api.linkedin.com, etc.). After that, the badges loaded without issue. That took me about forty-five minutes to diagnose because the initial error message was completely unhelpful.

Web Griffin Badge Of Honor Setup and Usage Guide

The basic approach is simple. You include a small script tag in your HTML, then drop a <bo-h-badge> custom element wherever you want a badge to appear. The widget handles the rest — it fetches the data, formats it, and injects it into the DOM. Here's what the minimal implementation looks like: <script src="https://cdn.badgeofhonor.com/widget.js"></script> Then inside your page: <bo-h-badge github="username" />

That's it for a single GitHub badge. The widget supports multiple attributes — linkedin, twitter, stackoverflow, npm, github, and a few others. You can stack multiple badges on one page by using multiple custom elements or nesting them inside a container. The CDN-hosted version means you don't need to self-host anything, which saves time but introduces a dependency on their infrastructure. One thing beginners miss: the extension and the widget are separate things. The browser extension version adds badges to OTHER people's profiles when you browse the web — useful if you want to show off your own stats on GitHub or LinkedIn pages. The JavaScript widget is what you put on YOUR site. People conflate the two and end up confused about why the extension isn't doing what they need. They do different things. The widget also supports custom styling through CSS variables. If you're working within a design system with strict color tokens, you can override the defaults without forking the code. The available variables are --bo-h-bg-color, --bo-h-text-color, --bo-h-border-radius, and --bo-h-font-family. That's not a lot of customization, but it covers the basics. If you need something more specific — like matching a dark mode theme automatically — you're out of luck unless you write your own stylesheet overrides.

Here's another thing that's not obvious: the widget caches API responses in localStorage. That's helpful for reducing API calls, but it means badge counts can be stale. I've seen clients complain that their GitHub star count showed as 0 immediately after a spike because the cache hadn't expired. The default TTL is ten minutes. If you need fresher data, there's no built-in invalidation mechanism. You'd have to clear localStorage manually or wait it out. For a personal portfolio that updates once a week, this doesn't matter. For a dashboard that someone checks hourly, it's annoying. Rate limiting is worth mentioning. Each platform has its own limits. GitHub's API allows unauthenticated requests at 60 per hour per IP. If you're putting twelve badges on one page and fifty people hit it in an hour, you'll start getting 403 errors. The widget doesn't warn you about this — it just fails silently. I solved it for a client by switching to authenticated API calls with a personal access token, which bumped the limit to 5,000 per hour. You set the token as a global config before loading the widget script. It's documented in their GitHub repo, but easy to miss if you're just following the quick-start guide. There's also a self-host option if you don't want to rely on their CDN. The source code is available on GitHub under an MIT license. Self-hosting means you download the widget bundle and serve it from your own domain, which solves the CSP issue I mentioned earlier and eliminates the external dependency. The tradeoff is that you're responsible for updating the code when they release new features or fix bugs. I'd recommend self-hosting if you're already comfortable managing frontend dependencies, otherwise stick with the CDN version.

One more thing: the widget doesn't support server-side rendering out of the box. If you're using Next.js or a similar framework with SSR, the badges won't render on the initial page load — they only appear after the client-side JavaScript executes. This causes a layout shift and a flash of empty space. The workaround is to use the no-ssr pattern or wrap the badges in a component that only mounts on the client. It's standard practice for this kind of thing, but if you're new to it, it'll catch you off guard. The tool works for what it does. It's not going to replace a full analytics dashboard or a custom-built social proof system. But if you need to display a handful of social stats on a portfolio, resume site, or documentation page without writing a bunch of API integration code, it's a reasonable solution. Just be aware of the caching behavior, rate limits, and SSR limitations before you commit to it.