Logo, favicon and custom CSS

logo

Two mutually exclusive forms. An image pair:

json

{ "logo": { "light": "assets/mark.svg", "dark": "assets/mark-dark.svg" } }

Or a text-only brand mark:

json

{ "logo": { "text": "Acme" } }

Setting text alongside light or dark is a schema error, not a precedence question.

currentColor does not work in a logo

Logos render as images. An SVG whose fill is currentColor has no text colour to inherit through that path — it renders black or invisible, depending on the file.

Supply two files with baked colours. A single-file monochrome mark that looks correct inline in your README will not survive being used as a logo.

favicon

json

{ "favicon": "assets/favicon.svg" }

A local file path. It is emitted as a <link rel="shortcut icon"> with the correct MIME type.

customCss

json

{ "customCss": ["assets/overrides.css", "assets/fonts.css"] }

An ordered array of local CSS files. Their contents form L3, the highest layer of the cascade — above the template baseline and above your generated tokens. Order within the array is preserved, so later files win over earlier ones.

This is the right place for @font-face, for overriding a --reed-* token, and for anything else that must beat the template.

How paths resolve

Every local path in logo, favicon, customCss and seo.ogImage resolves relative to the directory docs.json lives in. There is no required asset directory — assets/ is a convention, not a rule.

Existence is checked by reed check, so a typo or a moved file fails before a build rather than producing a page with a broken image.

A value that is an absolute URL is left alone rather than treated as a path.

Where they land in the output

Logos are processed as build assets and land under _astro/ with hashed filenames. Favicons and OG images are plain URLs and land under _reed/. You do not reference these output paths yourself — Reed rewrites the references — but knowing the split explains why a logo filename changes between builds and a favicon’s does not.