Bolt.css: classless styles for plain HTML elements

A stylesheet that leaves your markup alone

Bolt.css provides a mostly reasonable set of styles for HTML elements without classes. The project describes it as basic styles for HTML elements, and the intended use is simple static sites, or a starting point that you then add your own classes to.

The design constraint is the interesting part. There are no CSS classes in the library, so a document that uses it keeps its markup as plain semantic HTML, with no utility class soup and no framework specific attributes. A heading looks like a heading because the stylesheet targets the heading element, not because the author added a class to it.

That is a real position rather than an oversight, and the readme is clear that this is not a complete solution with layout grids, components, utility classes and the like. It is also a much smaller thing than any of those. The features list has four entries: no layout support, no CSS classes, tiny, and dark and light modes. Two of those are limitations stated as features, which is a good way to set expectations.

The audience is therefore someone who wants a document to look presentable with a single stylesheet and nothing else: a personal site, a small project page, a quick prototype, a piece of documentation. If your work has a design system, you have already solved the problem this solves, and the interesting question becomes whether the classless approach is a constraint you would rather not have.

Where the styles came from, and why

The origin story is short and explains a lot about the result.

The author started from the HTML Elements Reference on MDN and modified it as needed. The stated reasons for building Bolt.css were three: to pay homage to HTML, to have an exercise to learn more of the lesser-known tags and elements, and to be able to use it in other projects.

That is a different brief from building a framework. The exercise framing is telling, because a project built as a way to learn the tag vocabulary produces a different stylesheet from one built to solve a layout problem. Elements that most people never use, and therefore never style, get attention, while the parts of CSS that a framework is built around, grids and flexbox utilities, are deliberately left out.

The result is a document that looks correct because the elements have been given sensible appearances, rather than because a layout system has arranged them. The design decisions follow from that. A table looks like a table. A blockquote is indented. Lists have markers. Links are coloured. Code is set in a monospace face. None of that needs a class, and none of it arranges a page.

The repository also contains the demo material that goes with the site, an index.html page, a demo-support.css and its minified version, and a handful of media files, which together suggest a site that demos the styles on real content rather than on a grid of swatches.

Installing it: a link tag, npm, or one copied file

There are three routes, and they differ in how much they commit you to a version.

The CDN route is a single link element in your head, and it carries a subresource integrity hash.

`<link rel="stylesheet" href="https://unpkg.com/boltcss/bolt.min.css" integrity="sha384-PSzHklU0wT897cBMg+9qlTsh9O0FtnWnfHus5/jGskSj518OHHoQug4Z2cAKCfcV">`

The readme notes that you will automatically receive updates and refinements as they are added, and that if you want to lock to a specific version you can add a version to the href, with the example given being a versioned URL.

The npm route is the usual two commands.

`npm i boltcss`

The package manifest for boltcss is small. It is published at version 1.0.1, its main entry is bolt.css, which is the unminified stylesheet rather than the minified one, the description calls it a classless CSS stylesheet, the licence is MIT, and the homepage is boltcss.com. The scripts object is empty, so there is no build step to run on your side.

The third route is manual. You can self host, or copy and paste the stylesheet into your project by taking bolt.css directly from the repository.

That third route is the one with the least surprise in it, and it is worth a sentence about the general trade. Taking the CDN link means your stylesheet changes without your deploy, which is a reasonable default for a stylesheet with no API and a small footprint, and an unwelcome one for a site whose appearance you have to reproduce exactly.

Dark and light modes, and what the demo shows

Dark and light modes are listed among the four features, alongside the two absences, and they are the one piece of behaviour in the library that is not simply about element styling.

A stylesheet that supports both modes has to decide how the mode is selected, and the readme does not describe the mechanism. There is no documentation of a class on the html element, no data attribute, no media query convention and no note about a prefers-color-scheme query. That is a genuine gap in the visible documentation, and it is the kind of detail you have to read the stylesheet to answer.

The demo assets in the repository give a hint of the shape of the thing. There is an index.html for the demo site, a demo-support.css alongside its minified version, and the media files that a demonstration page tends to need, an image, a poster frame, a short video and an audio clip. The CNAME file at the root is the GitHub Pages custom domain configuration, which is how boltcss.com is served from the repository.

Two things follow from that layout. The demo is the documentation for anything the readme omits, so the mode switching and the look of the styles are things to check in the demo page rather than in prose. And the demo-support.css is a separate file from bolt.css, which suggests the demo needs additional styling of its own, and that the shipped stylesheet is the small thing rather than the whole of what you see on the site.

Where Bolt.css is the wrong tool

Four limits, all of them consequences of the classless design.

The first is layout. There is no layout support, which means the stylesheet gives you a document that reads well vertically and refuses to do anything about columns, sidebars, grids or alignment. For a page that is one column of text, that is the entire job and it is done. For anything resembling an application layout, you are writing that CSS yourself, and at that point the question is whether shipping a classless base is buying you anything.

The second is theming. A classless stylesheet styles elements, and elements do not carry variants. If your product has a primary button, a danger button and a muted button, you are adding classes for that, and once you are adding classes for variants you are heading towards the utility class approach that the library explicitly declines to offer.

The third is the framework question. A React or Vue application with a component library already styles its components, and dropping an element level stylesheet on top of it produces a conflict of two systems styling the same tags. The stylesheet is for documents, and using it inside an application is a mistake that is easy to make and annoying to undo.

The fourth is the update channel. The CDN route gives you automatic updates with no version control, and the stylesheet is small enough that vendoring it is trivial, so the argument for taking unpinned updates is weak. The unpinned versioned example in the readme is 0.4.0, which is behind the current 1.0.1, and that is a hint about how the version numbers have moved.

MIT licensing and a release history that has slowed

The licence is MIT, declared in the package manifest and carried by a LICENSE file in the repository, so the stylesheet can be used in commercial and non commercial work, modified and redistributed, with the notice kept. This is not legal advice, and for a stylesheet the practical point is that vendoring it into a project is straightforward.

The release history is short and recent versions are spaced widely. Version 0.7.0 was published on 2024-04-03, 0.8.0 on 2024-10-22 and 1.0.1 on 2025-03-12, and the last push to the default branch was on 2026-07-22. The repository is not archived.

So the project is still receiving work, and the version scheme has moved through several minor versions to a 1.0 patch release. What the readme does not offer is a changelog, so the difference between 0.8.0 and 1.0.1 is not documented in the repository, and a reader who wants to know what changed has to compare the files.

For a stylesheet this is a smaller issue than it would be for a library, because the surface area is small and the behaviour is visible. The two things worth checking before you commit are the dark and light mode behaviour, which the readme does not explain, and the element coverage, which is best assessed by loading the demo page and looking at the elements you actually use.

The contribution model is informal, by the readme's own account. You are invited to open an issue for feedback or problems, and the author says they are open to new ideas and ways to improve the library, with an issues link and a link to the project for feedback.

Editorial conclusion

Bolt.css is the right choice for a small static site, a documentation page or a prototype that should look acceptable before anyone writes a line of CSS, and for anyone who wants to see what the browser's default rendering looks like with a light touch of styling. It is the wrong choice for an application with a design system, since there is no layout, no grid and no component layer, and a classless stylesheet cannot be themed through utility classes. Before adopting, load the stylesheet next to your own CSS and check that your heading scale and link colours survive contact with your content, and if you take it from the CDN, pin a version rather than taking the automatic updates.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. tbolt/boltcss on GitHub