GitHub QR code — profile, repo, gist, release

A GitHub QR code is one of the highest-signal codes a developer can hand out — it points at a profile, a repo, a gist, a sponsor page, or a release-asset deep-link, and the audience for it (other developers) is the audience least likely to mistype a URL and most likely to scan one. The catch is that the same GitHub URLs that read well in a browser tab break the moment they hit a printed surface: long paths, slashes that wrap awkwardly inside a poster caption, repo names that get renamed three months after the conference. The right way to make one is rarely "encode github.com/user/repo and call it done."

This post walks the URL patterns worth knowing, where to put the QR (last slide, business card, hackathon prize handout, README on swag), and the one architectural decision that decides whether the code still works in 2027 — wrapping the GitHub URL in a short link you control rather than encoding the raw URL.

A GitHub QR code is a URL QR code with five common shapes#

Every QR code is, mechanically, a URL encoder. What makes a GitHub QR code worth its own conversation is that there are five URL shapes that come up repeatedly, each with a different recommended use:

1. Profile — https://github.com/username. The "here's me" QR. Slides, business cards, conference lanyards.
2. Repo — https://github.com/username/repo. The "here's the project" QR. README on swag, sticker handouts, the back of a talk slide.
3. Gist — https://gist.github.com/username/<hash>. A code snippet without a repo. Lightning talks, blog posts in print, workshop handouts.
4. Sponsor page — https://github.com/sponsors/username. The "fund the work" QR. Open-source merch, conference donation cards, livestream overlays.
5. Release asset deep-link — https://github.com/username/repo/releases/latest (or /download/<tag>/<filename> for a specific binary). The "grab the build" QR. Hackathon prize handouts, beta-tester invites, embedded-device flashing instructions.

Each one is a different conversion. A profile QR earns a follow; a repo QR earns a star or a clone; a sponsor QR earns a few dollars; a release QR earns a download. Choose the one that matches the moment, not the one that feels most flexible.

Why a raw GitHub URL is the wrong thing to encode#

Here is the temptation. You have a repo at github.com/yourname/your-project. You drop it into a QR generator. The QR works. You print it on the back of a business card. Three months later you rename the repo to your-project-v2, or you transfer it to an organisation, or you move the whole thing to a new account. The old URL still 302s for a while — GitHub does a decent job of redirecting renamed repos — but the redirect doesn't carry the analytics, doesn't survive a transfer to a different owner, and definitely doesn't survive you deleting the repo and re-creating it under a clean name later.

The other reason this is the wrong default: the raw URL gives you no analytics. The scanner lands on github.com. GitHub knows. You do not. There's no view-count on a printed business card. The QR worked, somebody scanned, somebody arrived — you have no way to count any of it.

The fix is the same one the link-infrastructure playbook on owning what your URLs depend on lays out for every other surface: wrap the third-party URL in a short link you control, then encode the short link in the QR. Now the QR points at your.brand/gh (or your.brand/repo, whatever slug you pick), which 302s to GitHub. You can re-point the slug whenever GitHub changes underneath you. You can count the scans. The printed surface never changes.

The shorter URL has a second, quieter benefit at print time. A QR encodes more modules for a longer URL. https://github.com/yourname/your-project-with-the-long-name is significantly more modules than https://your.brand/gh. More modules means a denser code, which means a larger minimum print size for reliable scanning. A short-link wrapper makes the QR physically smaller on paper without giving up legibility. This is why the post on encoding short links inside a QR code generator instead of raw URLs treats the wrapper as the default, not the upgrade — it pays off on both the analytics side and the module-pitch side.

Where the GitHub QR actually goes#

Five placements where a GitHub QR code earns its place. Pick one per surface — putting four QR codes on one slide is the most reliable way to get zero scans.

The last slide of a conference talk. The slide stays up for the questions, the audience holds their phones up, the QR carries them to the repo of the thing you just demoed. Make the QR a quarter of the slide width, contrast it hard against the background, and put one line of mono text underneath with the URL spelled out for anyone who can't scan from where they're sitting.

The back of a developer business card. Profile QR on the back, name and contact on the front. The card itself is a developer's portfolio handoff — somebody met you, somebody pocketed the card, somebody scans it that night. The same playbook the tradeshow-booth QR code pattern lays out for booth signage applies at the card scale: one QR, one ask, one URL.

Hackathon prize handouts. The release-asset deep-link is the right shape here. Print a card with "Winner — Project X — your.brand/dl" and the QR. The QR points at /releases/latest, so the audience always gets the current build without you reprinting cards when v2 ships.

Open-source merch. T-shirts, stickers, laptop hangers, conference swag. The repo QR or the sponsor QR are both fine — repo for "go contribute", sponsor for "go pay". Both work. The decision is what the merch is for. A T-shirt for contributors uses the repo QR; a T-shirt sold to fund the project uses the sponsor QR.

README image on swag. A subtle one. Some projects print the README front matter on small cards as part of conference handouts — title, one-line description, QR for the repo. The card lives in pocket and gets scanned days or weeks later. The repo URL has to still resolve at scan time, which is the whole reason for the wrapper.

The picker — which GitHub URL is yours?#

The four-or-five-way decision laid out as a small interactive. Click a target type and you get the URL pattern, the recommended placement, and the rename-survival argument for wrapping it.

The rename-survival argument, in detail#

GitHub does redirect renamed repos. It does not redirect:

• Repos you delete and re-create under the same name in a different org.
• Repos you transfer to an account that already has a repo with that name.
• Usernames you change after a long history of activity (GitHub frees the old name, somebody else can take it, your old URLs now point at a stranger).
• Anchor-link fragments inside README files when you restructure the README.

These cases come up. The repo you printed on stickers in 2024 might not exist in the same place in 2026, and the redirect chain GitHub provides was never designed as a long-term print-archive contract.

A QR code is a print contract with your future self. The short link on it is the only piece you control.

The wrapper costs you nothing at print time and pays back exactly when the repo moves. The first time you transfer ownership of a project and watch the old printed QRs keep working because you re-pointed your.brand/proj to the new URL in a dashboard — that's the moment the wrapper feels like the obvious choice. Until then, it just feels like extra work.

Picking the slug#

Three patterns work for GitHub-targeted short links:

Single-letter slugs for personal use. your.brand/gh for "my GitHub". your.brand/p for "my project". Easy to type, easy to remember, hard to scale past two or three slugs.

Project-named slugs for repo QRs. your.brand/widget for the Widget repo, your.brand/cli for the CLI. Reads naturally in a printed caption, survives renames inside GitHub because the slug is yours not theirs.

Campaign-suffixed slugs for events. your.brand/widget-rsc for "Widget repo, shared at React Summit Cologne". Same destination, different slug per event — gives you per-event scan counts and lets you see which conference actually drove the stars.

The third one is the underused move. A repo can have one short link that gets all the scans, or it can have one short link per surface (talk, sticker, business card) and tell you which surface produced the result. The cost of the second approach is zero on a platform where slugs are cheap; the value is the data you couldn't otherwise see.

Design choices that matter for a developer audience#

A GitHub QR code lives on developer surfaces, which means the audience scanning it is more forgiving of design choices than a general consumer audience — and also more willing to notice when the design is sloppy. Three small calls worth making deliberately:

Mono caption underneath. Always print the URL in mono type below the QR. Developers will read it before scanning. If the QR fails to scan, the URL is the backup. If the QR scans, the URL is the receipt of where they're about to go. Don't omit the caption to save space; the caption is the trust signal.

Square or barely-rounded modules. Developer surfaces tend to be more contrast-tolerant than packaging, so you can run the QR closer to its raw form than you would on a soft consumer product. Square modules at high contrast read faster across more cameras. If you need round modules for visual reasons, follow the round-QR module-overlap math from the design-system post and stay at error correction level Q or H.

No octocat overlay. The GitHub mascot in the centre of the QR is a tempting move and a generally bad one. Logo overlays eat error-correction headroom; for a developer audience that's already used to scanning bare codes, the overlay buys nothing and risks the scan. Skip it.

Brand the surrounding card, not the code. If you want personality on a developer business card or conference handout, put it in the typography, the colour of the card stock, the layout. The QR itself stays clean. The branded short-links trust playbook makes the same argument for the URL caption — the trust accrues to your domain showing up under the code, not to the QR being styled.

What the platform side looks like#

The platform piece is small but worth wiring once. Whatever short-link platform you use needs three things:

1. A custom domain. your.brand, you.codes, anything you own. The redirect lives on your DNS, and even if the platform behind it changes someday, the printed QR stays valid because the URL it encodes hasn't changed.
2. Per-slug analytics. Scan count, scan time, scan geo, device split. The minimum useful set is "how many scans, when, from where" — that's enough to tell which conference produced contributors and which one produced silence. The short-links setup docs walk through the slug-creation step on the platform side.
3. Editable destinations. The whole rename-survival argument turns on this — repoint a slug and the old QR now resolves to the new URL without any reprint.

That last one is the most important. A short-link platform that doesn't let you change the destination of a slug after creation is, for QR purposes, identical to encoding the raw URL. The whole point is to be able to repoint, and to know about it before your audience does.

The analytics side is worth thinking about as a feedback loop, not just a counter. If a sticker run goes out and produces zero scans, the campaign didn't work. If a conference talk produces 80 scans, you know the talk landed. The cost of finding that out is one toggle on the platform; the value is the next decision you make with the data. The analytics docs cover the per-slug view and the export side.

When the raw URL is actually fine#

In fairness, there are a few cases where a raw GitHub URL in a QR is fine:

• One-off, never-printed surfaces. A QR you generate to share over screen-share and discard. No print, no archive, no rename risk.
• Throwaway demos. A workshop QR for a repo that won't exist next week. You're not going to renumber it.
• Audiences who type, not scan. Some technical audiences will look at the QR caption and type the URL themselves. If you're confident the audience won't scan, the QR is decoration and the URL underneath does the work. The QR being raw doesn't matter.

Those cases are real and not large. Most GitHub QR codes worth making are made because somebody will print or distribute them, and the moment print enters the picture, the wrapper earns its place. The general rule from the QR codes docs on the platform side is the same one print designers reach independently — print is a commitment, the URL on it has to outlive the print run.

Sourcesshow citations

• GitHub Docs — About repositories and renaming — https://docs.github.com/en/repositories/creating-and-managing-repositories/renaming-a-repository
• GitHub Docs — About GitHub Sponsors — https://docs.github.com/en/sponsors
• GitHub Docs — Linking to releases — https://docs.github.com/en/repositories/releasing-projects-on-github/linking-to-releases
• GitHub REST API documentation — Releases endpoint — https://docs.github.com/en/rest/releases
• GitHub Octicons — Open-source icon set — https://primer.style/foundations/icons
• Wikipedia — GitHub — https://en.wikipedia.org/wiki/GitHub
• qrcode.js — Open-source QR encoder library README — https://github.com/davidshimjs/qrcodejs
• ISO/IEC 18004:2024 — QR Code bar code symbology specification — https://www.iso.org/standard/83389.html