Open Source Projects — entry 008 of 8
Shields
Shields.io serves status badges as SVG by default from `img.shields.io`, with `.png` requests 301-redirected to a raster-conversion host and a `.json` suffix returning the same badge's label/value/color as plain JSON — all three confirmed live. A live unauthenticated GET returned `Access-Control-Allow-Origin: *` on every format, resolving cors "unknown" to "yes". Free, open-source, and keyless, funded by sponsorships rather than a paid tier.
Shields renders the same badge in three formats from one path: SVG by default, PNG via a raster host, and raw badge data via a `.json` suffix. A live GET to `/badge/build-passing-brightgreen.json` returned a 200 JSON body with `label`/`message`/`color`/`name`/`value`, and `access-control-allow-origin: *` confirmed keyless cross-origin access — both reconfirmed by this run's own probe.
GreatAPIs Score
Embed this badge
<a href="https://greatapis.com/api/shields/"><img src="https://greatapis.com/badge/shields.svg" alt="Scored 94 on greatapis.com"></a>Auth quickstart
- No API key or signup required — every probe in this file returned a real badge with no auth header sent at all.
Your key is stored only in this browser (localStorage) and sent directly to the API — never to greatapis.
Fetch a static badge as JSON data instead of an image
GEThttps://img.shields.io/badge/build-passing-brightgreen.json
{"label":"build","message":"passing","color":"brightgreen","link":[],"name":"build","value":"passing"}Captured byte-for-byte from this run's live probe. Every field here is echoed straight from the URL's own `label-message-color` path segments, not looked up from stored data — request a different label/message/color and every field in the body changes to match.
Developer reference
https://img.shields.ioGotchas & limits
- The default response format is an image, not data: the exact same path without `.json` — `GET /badge/build-passing-brightgreen` — returned HTTP 200 with `content-type: image/svg+xml;charset=utf-8` and a full inline `<svg>...</svg>` body. `.json` is the opt-in data format, not the default.
- `.png` doesn't serve raster data from `img.shields.io` itself, it redirects: a live GET to `/badge/build-passing-brightgreen.png` returned `HTTP 301` with `location: https://raster.shields.io/badge/build-passing-brightgreen.png` — a client that doesn't follow redirects gets nothing from the host it asked.
- An unrecognized suffix doesn't error, it renders an error *as a badge*: a live GET to `/badge/build-passing-brightgreen.zzz` still returned `HTTP 200` with `content-type: image/svg+xml;charset=utf-8` and an SVG whose visible text reads "404: badge not found" — a client that only checks the status code will treat a broken badge as a success.
- Dynamic (non-static) badge routes work keyless too, not just the `/badge/...` static generator: a live GET to `/github/stars/withastro/astro.json` returned `HTTP 200` with body `{"label":"stars","message":"61k","color":"blue","link":["https://github.com/withastro/astro","https://github.com/withastro/astro/stargazers"],"name":"stars","value":"61k"}` — the same `.json` opt-in format applies across both badge families.