tailwindcolorshades: Eleven Shades From One Base Color

Eleven shade stops come out of one input color

The tool answers one narrow question: given a single color, what should a Tailwind palette look like? You pick a color in the picker or paste its code into the picker input, and the generator produces the ladder Tailwind projects tend to expect: 50, 100, 200, 300, 400, 500, 600, 700, 800, 900 and 950. Eleven stops, running from light to dark, all derived from the value you entered. The README describes the intent as custom scales that keep consistent visual harmony and proper contrast across every shade level, and it presents the project as a helper rather than a theme editor. That scope is narrow on purpose. There is no page for building a component library, no typography control, no alternate dark mode palette. If you are starting from nothing and want a whole design system, this is not the tool. If you already know the brand color and need a defensible ladder of tints and shades around it, that is precisely the gap it fills.

One generator, two Tailwind configuration shapes

Both Tailwind CSS v3 and v4 are supported, and that distinction is not cosmetic, because the two versions expect theme values in different places and the generator has to emit a matching shape for each. The dependency list pins tailwindcss ^4.1.18 and @tailwindcss/vite ^4.1.18, and the README describes the export step as copying the generated configuration to your clipboard and pasting it into your Tailwind config file. Picking the wrong target version is the most likely way to end up with output that looks right in the browser preview and fails the moment you paste it into a real project. The version choice is exposed in the interface rather than guessed, so the loop is: choose the version, choose the base color, copy, paste. What the README does not document is any validation pass after the paste, so treat the exported configuration as a starting point you still have to check against your own build.

OKLCH output and two color libraries in the dependency list

OKLCH, RGB and HEX are the supported output formats, and the README lists OKLCH first among them. That ordering is a design signal, since OKLCH is a perceptual space and an even lightness step in it usually produces a smoother visual ramp than a naive blend in sRGB. Whether the current implementation leans on that property everywhere is not something the repository documents in detail. What the package manifest does show is two separate color libraries in devDependencies, chroma-js ^3.2.0 and culori ^4.0.2, along with type packages for both of them. Two libraries in one project usually means one is legacy or one covers a specific conversion, and the manifest gives no hint about which role each plays. For an adopter the practical point is narrower: the format list is a claim you can check in two minutes by comparing generated hex values against your own expectations, and no documented statement covers how values are rounded or clamped near the ends of the range.

Import, edit, copy: the round trip through your clipboard

Two listed features make this more than a one way converter. The first is import, which loads an existing Tailwind color configuration so you can modify a palette you already have rather than starting from zero. The second is selective export, where you choose which of the eleven shade levels to include, which is handy when you want a short scale rather than the full run of stops. Export itself is a clipboard copy, and the README mentions no file download, no generated plugin and no diff, so the copy action is the only integration point. Everything the tool produces still has to be pasted into your config by hand. That is a fine trade for a single palette and a tedious one if you maintain several themes, and it is worth knowing before you build a repeatable workflow around it.

Palettes travel by URL, not by a file

URL sharing is on the feature list, so a palette can be handed to a colleague as a link instead of a wall of hex values. The repository also carries a public directory and a .ga directory, and the live demo is served from GitHub Pages at javisperez.github.io/tailwindcolorshades, which means the deployed build is what most people will actually touch. The primary language of the repository is Vue, the manifest pins vue ^3.5.26, and the build pipeline is Vite with a vite.config.ts at the root of the project. Nothing in the README describes what the URL parameters contain, whether they are validated, or how long a shared link stays meaningful. The practical effect is that a shared link is the only durable record of a palette outside your own clipboard, so treat those links as project state worth saving.

A pnpm workflow with an empty test suite

The development instructions assume Node.js 22 or newer and pnpm, and the repository ships a pnpm-lock.yaml next to a .nvmrc file, so the local setup is pinned to one package manager rather than npm. Four commands cover the whole loop: install, dev server, production build and lint. The lint script is a composite that runs oxlint and eslint in sequence through npm-run-all2, and the build script runs a type-check with vue-tsc ahead of the Vite build, so a type error stops the bundle instead of producing broken output. The test command is the weak point. The README labels the section with a TODO, the repository does contain a vitest.config.ts, and jsdom and @vue/test-utils both appear in devDependencies, so the harness is wired up while the suite is not. No test files show up in the top level listing, which matches that TODO. If you intend to fork and extend the shade algorithm, you start without a regression net, and pinning the eleven generated values for one fixed base color would be the first useful test to add.

pnpm install

That installs the dependency tree from pnpm-lock.yaml.

pnpm dev

That starts the Vite development server with hot reload.

pnpm build

That type-checks with vue-tsc and then produces the minified build.

pnpm lint

That runs oxlint and eslint in sequence.

pnpm test:unit

That runs Vitest, although the README marks testing as a TODO.

Where the generator is the wrong tool

Several common needs sit outside its reach. It works from one base color, so a palette built on two distinct hues, a tinted near neutral gray, or a set of semantic roles such as success, warning and danger has to be produced somewhere else. The eleven stops are fixed and mirror the Tailwind naming convention, so a project that already settled on a different scale cannot adopt them as they are. The README names proper contrast as a goal but documents no contrast checker and no accessibility audit, so you verify the ladder yourself. Nothing describes a batch mode, a CLI or an API, and automating palette generation across many themes means driving the browser interface yourself. There is also no documented history, undo or project storage, so palette state lives in the URL and the clipboard.

Licensing and the cost of picking it up

The README states that the project is open source and available under the MIT License, while the repository listing carries no license identifier, so check the license file yourself before shipping the tool in a commercial product rather than relying on a README sentence. Adopting the tool also costs less than it first appears: it is a browser application with no server component, no runtime service and no API keys, so the only ongoing work is pasting output into your config and redoing it whenever the base color changes. The generator itself is the dependency; there is no package to install in your app. For a team that already works in Tailwind and has a fixed brand color, the real cost is the copy and paste step and the absence of tests in the repository, not the size of the codebase.

Editorial conclusion

Adopt tailwindcolorshades when you need a consistent eleven step ladder around one brand color and you are happy to paste the result into a Tailwind config by hand. Skip it when your palette needs several hues, semantic roles or batch generation across themes. Before you commit, generate a palette for a color you already ship, paste it into a real build, and compare the rendered shades with the ones you have today. The last push was on 2026-10-19, and the README names the MIT License, so confirm the license terms yourself before shipping it.

Frequently asked questions

Official sources

1. Issues
2. javisperez/tailwindcolorshades on GitHub
3. README