Skip to main content
A publish renders the resolved theme into up to five files. They are five views of the same thing — pick the one your stack wants.
Your Theme does not serve all five. It serves only what its integrations require, and asking for anything else returns 404. The table further down maps integration to files; the portal’s Integration tab and the API’s servingUrls both list the URLs that actually exist.

​
tokens.css

The zero-code integration. A <link rel="stylesheet"> is a complete one.
Property names are the token path, hyphen-joined, with an optional prefix:
The prefix is a Theme setting. If you generate CSS that references these properties, read it from the Theme’s assetSettings.prefix rather than assuming it is empty.
It is a lossy projection, and it says so in the file. CSS has no token types, no groups and no descriptions, and several DTCG values have no CSS spelling at all — a stroke style with a dash array, a colour in a space CSS cannot name.A token that cannot be written becomes a comment naming its path, rather than being dropped silently or guessed at. Diff the stylesheet against your tokens and you can see exactly what is missing and why.
Characters that could end a declaration or open a block are refused rather than escaped, so a token value cannot escape its declaration and inject CSS into your page.

​
tokens.json

The full DTCG document, resolved: the tree, the groups, $type, $description, $extensions, and every alias replaced by the value it pointed at. Use it when you want the structure and the metadata — building a theme editor of your own, or driving a token pipeline that cares about types.

​
tokens.dtcg.json

The same document with aliases left as written.
This is the one to feed a DTCG tool — Style Dictionary and friends resolve references themselves, and handing them a pre-resolved document throws away the relationships they are built to use.

​
tokens.flat.json

Dotted path to the typed value. Use it when you want to look a token up by path without walking a tree, and you care about its structure.

​
tokens.values.json

Dotted path to the value as a CSS string. This exists for libraries that derive shades or contrast from a colour in JavaScript. Those cannot read a var() — they need a real value — so they get this file instead of tokens.css.
A theme built from this file does not rebrand by swapping a stylesheet. The values are baked into your JavaScript at fetch time, so switching Variant means re-fetching and re-rendering. That is the cost of a library that computes on values, and it is why tokens.css is preferred wherever a library will accept var().

​
Which files your Theme builds

Decided by the library half of each integration pair: A Theme with several integrations builds the union. Adding an integration builds the extra files on the next materialisation; removing one deletes the files nothing else needs, for every published version.
MUI, Vuetify, PrimeVue and PrimeNG are placed on tokens.values.json conservatively — chosen because those libraries have historically computed on values, not verified against each library’s current version. If yours accepts var() throughout, ask us to move it; it is a one-line change and costs you a smaller payload.

​
Content types

Plain application/json, not the application/design-tokens+json the DTCG spec suggests. That type is not IANA-registered, and fetch().json() and every CDN’s compression rule key on the plain one.