What Carbon actually is
Carbon is described by IBM as its open-source design system for products and digital experiences, with the IBM Design Language as its foundation, consisting of working code, design tools and resources, human interface guidelines, and a community of contributors. It is funded and built by IBM for IBM's business needs, and released openly for anyone to use and contribute back to.
That funding model is worth pausing on, because it determines what you are adopting. Carbon is not a community project that happens to have corporate users; it is a corporate system that happens to be open. Roadmap decisions serve IBM products. In practice that is mostly good — it means the system is genuinely maintained rather than abandoned when a maintainer changes jobs — but it also means a feature your product needs and IBM's do not is unlikely to arrive.
The name is a metaphor the team states directly: carbon in nature builds complex structures from simpler compounds, mirroring how individual styles and components combine. Worth knowing because it explains the system's bias toward composition over prescription.
The three layers
The structural decision that makes Carbon worth studying is that it is not one system. IBM publishes a stack, and the separation between the levels is explicit in the navigation of the site itself.
| What it holds | Who changes it | |
|---|---|---|
| IBM Design Language | Brand foundation: the visual and expressive language across all of IBM | IBM brand, rarely, and never for a product's convenience |
| Carbon Design System | Tokens, components, patterns, human interface guidelines, code | The Carbon team plus open-source contributors |
| Domain systems | Carbon for IBM Products, Carbon for Cloud, Carbon for IBM.com — components specific to one context | That domain's team, without touching the core |
This is the same shape Spotify arrived at with Encore, reached from a different direction, and it solves the same problem: where does a component go when only one product needs it? Without a domain layer, the answer is either "into the core, making it heavier for everyone" or "outside the system, where it drifts". With one, specialised work has a home that cannot leak.
If you are building a system for more than one product, this is the single most transferable thing in Carbon. You do not need three published sites. You need a rule about which of your three levels a given decision belongs to, and the discipline not to let a product-specific need get promoted into the foundation because it was easier.
Framework support is not uniform, and the docs say so
Carbon supports multiple code implementations, and the documentation lists each one with its maintainer. That list is the most practically important thing on the site if you are evaluating adoption:
| Maintainer | What that means for you | |
|---|---|---|
| Elements | Carbon team | First-party. Tokens, type, colour, icons, grid |
| React | Carbon team | First-party and the most complete. The default choice |
| Web Components | Carbon team | First-party. Framework-agnostic, viable if you are not on React |
| Angular | Community | Evaluate release cadence and issue response before committing |
| Vue | Community | Same caveat |
| Svelte | Community | Same caveat |
"Community maintained" is not a criticism, but it is a risk you are taking on rather than one IBM is carrying. Before adopting a community implementation, check the last release date, how far behind core it is, and how quickly issues get responses. A design system that lags the core by two majors is a migration you have not budgeted for.
The honesty here is worth noting as a documentation practice in its own right. Plenty of design systems list framework packages without saying who is responsible for them, which leaves adopters to discover the difference during an incident.
Carbon MCP: the part nobody has written about
Carbon MCP is available as a public preview. It is a Model Context Protocol server that gives AI agents and AI applications direct access to the Carbon knowledge base — core elements, iconography, pictograms, guidelines, usage documentation, and component libraries across React and Web Components, plus the Carbon for IBM Products library.
The documented tools are specific, and reading them tells you exactly what problem IBM thinks it is solving:
| What it searches | |
|---|---|
docs_search | Carbon and IBM Products documentation — component guidance, usage, accessibility, reference |
code_search | Carbon React and Web Components code examples, icons and pictograms, as complete example application files |
get_charts | Carbon Charts examples across React, Angular, Vue, Svelte, vanilla JS and HTML |
labs_search | Carbon Labs experimental components — AnimatedHeader, Processing, Resizer, WhatsNew, Labs UIShell |
IBM's stated reasons are instant AI access to Carbon standards, higher-fidelity code generation from real examples, and improved consistency from a shared source of truth that reduces drift and rework. Access during the preview is immediate for IBMers; others request it through an early-access form.
The significance is not that IBM built an integration. It is what the existence of the server concedes: a model's training data is not a reliable source for a design system's current API, and asking it to write Carbon code from memory produces components that are plausible and wrong. The server exists because retrieval beats recall.
The server exists because a model's memory of your component API is confidently out of date, and a wrong prop name looks exactly like a right one.
Carbon is not alone in this
Read across the three large openly published enterprise design systems and the same move appears three times in eighteen months, executed differently:
| The move | The bet | |
|---|---|---|
| IBM Carbon | An MCP server exposing docs and code examples | Agents should retrieve the system at generation time |
| Salesforce Lightning (SLDS 2) | A CSS architecture decoupled from the visual style, plus a linter that validates markup against the rules | The system should be themeable enough for generated UI, and violations should be caught mechanically |
| Shopify Polaris | React deprecated in favour of framework-agnostic web components served from a CDN | The delivery format should not assume which framework generated the page |
Three different bets, one shared premise: the consumer of a design system is no longer only a human developer reading documentation. That premise is not controversial any more, but the fact that all three acted on it within a year and a half is not something the design system literature has caught up with.
MCP and DESIGN.md solve different halves
It is tempting to read Carbon MCP as making file-based design guidance obsolete. It does not, because the two answer different questions.
| An MCP server | A DESIGN.md in the repo | |
|---|---|---|
| Answers | How do I use this component correctly? | What should this product look like? |
| Source of truth | The library's maintainers | You |
| Loaded | On demand, when the agent asks | Every session, as context |
| Covers | API surface, props, accessibility, examples | Roles, scale, prohibitions, motifs, what not to do |
| Without it | The agent invents props that do not exist | The agent invents a design that is not yours |
An agent with Carbon MCP and no design guidance produces technically correct Carbon components arranged into an interface with no point of view. An agent with strong design guidance and no MCP produces a well-judged layout calling props that were renamed in v11. You want both, and they do not overlap.
We sampled 299 DESIGN.md files published for agents to read, and the numbers show which half is currently being neglected: 86% specify colours as raw hex with no semantic role, 76% state no prohibitions at all, 57% define no distinctive motifs, and 69% say nothing about dark mode. Those are all the second column — the questions an MCP server was never going to answer.
Identity Forge design kits fill that column: semantic colour roles across light and dark, a type and spacing scale, motifs, and an explicit do's and don'ts list, serialised into a DESIGN.md that sits alongside whatever component library you use. Browse the kits, or read what a DESIGN.md file is.
Should you adopt Carbon?
Carbon is a genuinely good system and adopting it is frequently the wrong call. The deciding factor is whether you want a design opinion supplied to you.
| Adopt Carbon | Do not | |
|---|---|---|
| Product type | Internal tools, enterprise admin, data-dense applications | Anything where visual differentiation is part of the value |
| What you get | Accessibility work already done, a large component set, real maintenance | An interface that reads as IBM's, because it is |
| Team shape | No dedicated design resource, engineers making UI decisions | A designer with a point of view who will spend six months overriding it |
| The tell | "We need this to be usable and consistent, fast" | "We need this to look like us" |
The accessibility argument deserves its own weight. Carbon's components have had real accessibility work invested in them over years, backed by IBM's accessibility practice. Reproducing that on your own component library is a multi-year commitment that most teams start and abandon. If your product is an internal tool, taking Carbon's is close to a free win.
The counter-argument is that a design system carries an identity, and Carbon's is IBM's. Themable does not mean neutral: the density, the shape language, the type treatment and the interaction idioms all encode decisions made for IBM products. If your product competes partly on how it feels, you will spend more energy fighting those than you would have spent defining your own system.
What to steal even if you never install it
- Separate brand language from implementation. IBM Design Language and Carbon are different documents with different owners and different change rates. Merging them means every component tweak becomes a brand conversation.
- Give domain-specific work a domain layer. A component only one product needs belongs above the core, not in it and not outside the system.
- Publish who maintains each implementation. Adopters are making a risk decision. Let them make it with the facts.
- Expose the system to agents deliberately. Whether that is MCP, a machine-readable token export, or a well-structured file in the repository, the agent is going to write against your system either way. The only question is whether it does so from your documentation or from its training data.
Is the Carbon Design System free to use?
Yes. Carbon is open source, funded and built by IBM but released for anyone to use and contribute to. Check the licence in the repository for the current terms before shipping commercially, as licensing is a per-package fact rather than a project-wide one.
Which Carbon framework implementation should I use?
React if you can — it is maintained by the Carbon team and the most complete. Web Components if you are not on React and want first-party maintenance. Angular, Vue and Svelte are community-maintained, which is workable but means checking release cadence and issue response before you commit a product to them.
What is Carbon MCP and do I need it?
It is a Model Context Protocol server, currently in public preview, that lets AI agents query Carbon's documentation, component code examples, charts and experimental Labs components directly. You need it if agents write Carbon code in your repository — without it they generate from training data, which is confidently out of date on prop names and imports.
Can I make Carbon not look like IBM?
Partly. Tokens let you change colour, type and some shape properties. What you cannot easily change is the density, the interaction idioms and the component composition, which is where a large part of the perceived identity lives. If "it must look like us" is a real requirement, budget for that fight before adopting.
How does Carbon compare to Polaris and Lightning?
All three are large, openly published enterprise systems built for a specific parent product. Carbon is the most framework-plural and the only one shipping an MCP server. Polaris has deprecated its React library in favour of framework-agnostic web components. SLDS 2 rebuilt its CSS architecture around custom properties to decouple structure from visual style. Their design opinions differ more than their capabilities do.