Hosting the badge
The SVG needs a stable URL for your README to reference. Three options, from simplest to most robust:Option 1: Commit to your repo
Generate the badge and commit it directly:Option 2: Publish from CI (recommended)
Add a step to your CI workflow that generates the badge and publishes it to abadges branch:
- GitHub Actions
- GitLab CI
badges branch:Option 3: Shields.io endpoint
If you prefer dynamic badges via shields.io, generate a JSON endpoint file instead:badges branch) and use the shields.io endpoint badge:
raw.githubusercontent.com, which cannot read private content. See Private repositories.
Private repositories
raw.githubusercontent.com (Option 2) and the shields.io endpoint (Option 3) only render for public repositories. Both hosts serve raw content with no access to private repos, so the badge shows as a broken image. Putting a personal access token in the URL is insecure and against GitHub’s terms, so avoid that.
For a private repo, commit the badge into the repository and reference it with a relative link. GitHub renders relative image links for any viewer with read access to the repo:
badges branch:
permissions: contents: write. A relative link resolves against the branch the README is viewed on, so the badge has to live on that branch: a separate orphan badges branch (Option 2) cannot be reached by a relative link, which is why private repos commit the badge directly.
Monorepo badges
For workspace packages, scope the badge with--workspace:
Technical details
- Self-contained SVG with embedded Verdana font metrics. No external requests
- Unique element IDs per badge, so you can inline multiple badges on one page
--format badgeautomatically enables--score(no need to pass both)- Exit code 2 with an error message if the score cannot be computed
- Also available via the
FALLOW_FORMAT=badgeenvironment variable