Open Props: a CSS variable set that also exports design tokens to Figma

Eleven categories of variables, one stylesheet

The pitch fits in two lines. Open Props describes itself as open source CSS variables for adaptive and consistent design, and the category list runs: colors, gradients, shadows, aspect ratios, typography, easings, animations, sizes, borders, z-indexes and media queries.

That list is the whole product. There is no runtime, no build step required to use it, and no JavaScript in the critical path. You link a stylesheet, the custom properties land in your document, and every one of them is a normal CSS variable you can override.

What that means in practice is that `--size-1` through `--size-fluid-*` and the color scales are names you will find already understood by anyone who has worked with the library. The topic list on the repository is more informative than the README badge row: css, css-colors, css-custom-media-queries, css-custom-properties, css-easing-functions, css-gradients, css-normalise and css-utilites. Custom media queries matter more than they sound, since they let you define breakpoints as variables rather than repeating pixel values in every media query.

The CDN line and what the other exports are for

The quickest way to use it is a single link, and the README lists several endpoints. The bare `https://unpkg.com/open-props` gives you everything. There is a separate `normalize.min.css` for a light and dark normalize variant. Then there are four token files that are the more interesting half:

open-props.tokens.json
open-props.figma-tokens.sync.json
open-props.style-dictionary-tokens.json

One is plain design tokens, one is shaped for Figma's token sync plugin, and one is shaped for Style Dictionary. That is three representations of the same values, and picking the right one saves you from writing a converter.

The Figma export is the reason a lot of designers know this project at all. If your design tokens live in Figma and your CSS wants to match, that sync file is the bridge, and it is a specific enough feature that it changes how you would evaluate the library. The value is real, but it is also a one-way convenience: hand-editing values on the CSS side and expecting Figma to follow does not work, because the direction is design tool to code.

Five generated variants, each answering a different compatibility question

The CLI section is the part that tells you the author has actually shipped this in difficult environments. Five generation targets:

npm run gen:op
npm run gen:nowhere
npm run gen:shadowdom
npm run gen:prefixed
npm run bundle
npm run lib:js

The default build runs the JavaScript files in `src/` to produce the PostCSS files there. The `gen:nowhere` target builds a version without `:where()`, which exists for the cases where you need specificity you cannot otherwise get. The `gen:shadowdom` variant swaps the scope to `:host`, for use inside a web component's shadow root where `:where()` at the document level would never match.

The `gen:prefixed` variant is the one to think about hardest. It produces a build where every property carries an `op` prefix, like `--op-font-size-1`, which is exactly what you want when your variables might collide with a design system from another vendor or a framework's own custom properties.

Having all five generated is generous, and it is also a maintenance cost for whoever maintains it. You have to decide which one is canonical, or you will end up patching two.

Testing, the package shape and what version 1.7.23 actually means

The testing instructions are two commands:

npm run build && npm run bundle
npm test

A workflow badge for tests.yml sits near the top of the README, so the build is covered by CI rather than being a suggestion.

The npm package metadata is more revealing than the README. It is `"type": "module"`, version 1.7.23, with `style` pointing at `open-props.min.css`, `main` at `dist/open-props.cjs`, `module` at `dist/open-props.module.js`, `types` at `dist/open-props.module.d.ts`, and an `exports` map that also publishes deep entry points per category: `./src/colors`, `./src/easing`, `./src/fonts`, `./src/gradients`, `./src/borders`, `./src/aspects`, `./src/animations`, `./src/media` and more. That last part matters for bundle size: you can import one category rather than the whole set, which is the difference between a design token library being free and being a megabyte of dead CSS.

One caveat worth knowing: the GitHub releases stop at v1.6.0, published 2023-09-29 and titled as a step toward v2, while the package version is 1.7.23. Releases are not being cut for routine work; the npm version is the one to track. A related search for "Open-props v2" reflects people asking about a version that has not shipped as a release.

How this sits against Tailwind and against nothing at all

"Open Props vs Tailwind" is one of the related searches for this project, and it is the right comparison to make, though the two solve different halves of the problem.

Tailwind gives you utility classes, which means the styles live in your markup and every decision is visible at the point of use. Open Props gives you variables, which means the styles live in a stylesheet or in arbitrary values like `var(--size-fluid-3)`, and the class names stay semantic. The practical difference is that Open Props does not care how you write your CSS, while Tailwind decides for you. Teams that already have a CSS architecture usually find the variables compatible with it; teams that want to delete their stylesheet find Tailwind the better fit.

The comparison people skip is with doing nothing. A design token set is a coordination artifact. Its value is largest in a team where several people are making the same kinds of choices independently, and near zero in a solo project where you would have written twenty lines of `:root` yourself. That is not an argument against Open Props, it is an argument for deleting the 80 percent of the variables you never reference.

Editorial conclusion

Open Props earns its place as a starting palette rather than as a design system. It solves the first week of a project, when nobody has agreed on what --gray-3 means or how many shadows exist, and it does that in one stylesheet line. What it does not do is decide your type scale or your spacing rhythm for you, and adopting it wholesale means importing a lot of values you will delete. Verify three things first: whether your build tolerates the `:where()` scoping the default build uses, whether the Figma token import survives a round trip, and which of the generated variants you actually want to maintain. Start with the CDN link, delete what you do not use, and only then decide whether the token exports earn their place in your pipeline.

Frequently asked questions

Official sources

1. argyleink/open-props on GitHub
2. License: MIT
3. Project website
4. README
5. Releases