WebGradients: 180 CSS Gradients With a JSON Dataset for Agents
180 free CSS3, Figma, Sketch & PSD gradients — plus a JSON dataset for design tools, generators, and AI agents.
At a glance
- What is it?
- WebGradients ships 180 gradients as a stylesheet, as Figma, Sketch and PSD files, and as a JSON dataset with per-stop positions. The CSS file is the easy part. The JSON is what makes it interesting to tooling, and the blend-mode dependency is what will bite you.
- Who is it for?
- Adopt WebGradients if you want a fixed, MIT-licensed set of 180 gradients as a stylesheet you can link without a build step, or as JSON you can feed to a generator or an agent. Do not adopt it if you need an API to search, filter or mutate gradients, a versioned npm package with a changelog, or gradients that avoid background-blend-mode entirely.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 43 days ago.
- What is it written in?
- Mainly CSS, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Gradients Are Easy to Write and Hard to Pick
A CSS linear-gradient is four tokens. Choosing the two colors and the angle is the part that stalls a layout. WebGradients answers that by fixing the choice: 180 named gradients, each with a defined angle and stop list, distributed as CSS3, Sketch, PSD and Figma files. The README describes the set as free for personal and commercial use and points to webgradients.com for browsing.
The second audience is less obvious and more interesting. The README says the same 180 gradients are available as structured JSON, described as useful for design tools, generators, or feeding gradient data to an LLM or agent. That reframes the project from a swatch gallery into a small dataset with a stable shape. If you are building a theme generator, a design-token pipeline, or an agent that emits CSS, a fixed set of 180 gradients with numeric stop positions is more useful than a screenshot grid, because the data is already parsed for you.
Who it is not for: anyone who needs to generate new gradients, blend two of them, or query by color. The set is closed at 180 and the README describes no API, no search endpoint, and no programmatic generator. You pick from the list or you do not use the list.
The JSON Schema Is the Real Interface
The README gives one example object, and it is worth reading closely because it defines the contract. A record has a name ("Warm Flame"), an index ("001", zero-padded as a string), a deg field described as the CSS gradient angle, a group array holding the dominant color or colors, and a gradient array of objects each with a color hex string and a pos value in percent.
Two files carry that shape. gradients.json is described as the full dataset with per-stop color positions. gradients-parsed.json is described as a flattened variant with a zero-padded index. The naming suggests the parsed file is the one you want if you are joining records to filenames or sorting by index, since a zero-padded string sorts correctly as text while an integer would not.
The design decision worth flagging is that group is an array, not a string. The example shows a single element, ["#F9AFAD"], but the type allows more than one. Any parser you write should treat group as a list and handle the multi-color case, even though the one documented example does not exercise it. The README does not say how many records have more than one dominant color. If that matters to your use case, count it yourself before you build logic on top of it.
Positions are percentages, so a two-stop gradient runs 0 to 100. The README does not state whether three-stop or four-stop gradients appear in the set, nor whether positions are always integers. Both are checkable in the file and neither is answered in the documentation.
Getting It Running: One Link Tag or One Fetch
The CSS path is documented in three steps. Download webgradients.css from the repository, place it in your project folder, and link it in the head of your document. The README gives this exact markup:
<html> <head> <link href="webgradients.css" rel="stylesheet"> </head> ...
There is no build step, no package manager command, and no configuration. That is the whole installation. The README does not list the class names the stylesheet defines, so you will be reading the file or the site to find the selector for a given gradient. That is a documentation gap, not a design flaw, but it changes the first ten minutes of use from copy-paste to inspection.
The JSON path has no documented fetch snippet at all. The README lists the two filenames and shows one example object, and that is the extent of it. If you are wiring the dataset into a build, you are choosing your own loading strategy and your own validation. Nothing in the material describes a schema file, a TypeScript type definition, or a version field inside the records.
The Figma route is separate: the README points to a community plugin page for the WebGradients plugin, which exposes all 180 gradients inside Figma. That is the shortest path for a designer and the least useful path for a build pipeline, since the plugin output is not described as exportable back to JSON.
background-blend-mode Is the Constraint to Check First
The README states plainly that some gradients use the background-blend-mode CSS property, and that it is supported by the majority of modern browsers, linking to Caniuse and MDN for detail. It does not say which gradients, and it does not say how many.
This matters more than it looks. background-blend-mode is a compositing property with a different support and rendering story from plain linear-gradient. A gradient that renders correctly in one engine can composite differently in another, and the failure mode is a wrong-looking background rather than a missing one, which is harder to catch in a screenshot diff. The README's own framing ("some gradients") tells you the set is not uniform: part of it is simple, part of it depends on a property you have to verify against your actual browser matrix.
If your target includes older browsers, embedded webviews, or email clients, treat the blend-mode subset as unusable until you have tested it. The practical move is to grep the stylesheet for background-blend-mode, count the matches, and decide whether you can drop those rules or need a fallback. The README offers no fallback guidance and no list of affected gradients, so that inventory is on you.
This is the single biggest gap between what the project looks like (a flat set of 180 interchangeable backgrounds) and what it is (a set with at least two rendering classes, only one of which is documented as universally safe).
Compared With a Utility Framework's Gradient Scale
Tailwind CSS is the obvious alternative, and the difference is not cosmetic. Tailwind generates gradient utilities from your theme configuration: you define the color stops, the framework emits the classes, and the output is tied to your design tokens. It scales to any number of gradients you want and integrates with the rest of your spacing, color and dark-mode system.
WebGradients inverts that. The 180 gradients are fixed and hand-picked, the colors are not derived from a token scale, and there is no configuration surface. You get a curated set with names and a JSON mirror, and you give up the ability to generate a 181st gradient that matches your brand palette.
That trade is reasonable in specific cases. Prototypes, marketing pages, demos and side projects benefit from not having to choose colors. So does anything that consumes the JSON: a fixed dataset with stable names is easier to reference from an agent prompt than a generated scale whose class names depend on a config file. A Tailwind scale is better when the gradients must match a brand system; WebGradients is better when the gradient is decoration and speed matters more than palette control.
The two are not mutually exclusive. You can link webgradients.css alongside a Tailwind build, though you then carry two sources of gradient truth, and the blend-mode subset still applies.
Maintenance, Versioning and the MIT Terms
The repository is licensed MIT, which the README states directly. In practice that means you can use the gradients in personal and commercial work, modify the CSS, and redistribute it, provided the licence and copyright notice are preserved. That is the general shape of MIT, not legal advice; read the LICENSE file in the repository for the operative text.
The maintenance picture is thin in a specific way. The README lists no releases, and the material retrieved shows none. There is no npm package, no changelog, no semantic version tag, and no version field inside the JSON records. You are tracking the master branch, or you are copying a file into your repository and owning it from that point.
Copying the file is the safer default. A linked stylesheet that updates under you can change the rendering of a page you already shipped, and because the records carry no version, you cannot pin the dataset to a known schema. Vendoring webgradients.css and the JSON files into your own tree makes upgrades an explicit diff rather than an ambient change.
Upgrade cost is therefore low but not zero. The CSS is a flat file, so replacing it is mechanical. The JSON is where the risk sits: if the schema changes (a field renamed, group flattened to a string, index reformatted), any parser you wrote breaks silently. There is no migration note to consult. The mitigation is a small validation step in your build that asserts the fields you depend on exist in every record.
What the Documentation Does Not Answer
Several questions a reader will have are simply not addressed in the supplied material. Whether gradients.json and gradients-parsed.json contain the same 180 records, or whether the parsed variant is a strict superset or subset, is not stated. Whether the two files use identical field names is not stated. Whether the index field is unique and contiguous from 001 to 180 is not stated.
The relationship between the CSS class names and the JSON name field is also unstated. If the stylesheet defines .gradient-001 or a slug of "Warm Flame", the README does not say. Anyone building a picker that maps a JSON record to a CSS class is inferring that mapping rather than reading it.
Finally, the README notes the project is donation-supported and describes the support as keeping the tools free, fast and ad-free. That is the only signal about funding, and it is worth reading as a signal about expected maintenance cadence rather than as a guarantee either way.
None of these gaps are fatal. All of them are checkable in an afternoon by opening the two JSON files and the stylesheet. The mistake would be assuming the documentation covers them.
Editorial conclusion
Adopt WebGradients if you want a fixed, MIT-licensed set of 180 gradients as a stylesheet you can link without a build step, or as JSON you can feed to a generator or an agent. Do not adopt it if you need an API to search, filter or mutate gradients, a versioned npm package with a changelog, or gradients that avoid background-blend-mode entirely. Verify three things before committing: whether gradients-parsed.json contains the same 180 entries as gradients.json, how many of the 180 rules use background-blend-mode, and whether the commit history shows the JSON schema changing after you have written a parser against it.
Community notes