HTMHell collects the HTML mistakes real production sites actually ship

A gallery of mistakes rather than a checklist

HTMHell is described as a collection of bad practices in HTML, copied from real websites, and the site is published at htmhell.dev. The distinction from a style guide or a linter is the point. Where a style guide tells you what to write, this shows you what shipped, which is a different kind of evidence. Markup that appears on a live site has passed through a build pipeline, a content management system, a component library and at least one deadline, so the mistakes in it are the mistakes that real teams make rather than the mistakes a beginner makes. The repository is an Eleventy site with the entries stored as markdown files, plus a data directory holding the authors and the shared snippets, and the primary language of the repository is Nunjucks because that is the template language the site is written in. The collection is presented as a teaching resource for front end developers, and the site itself is the delivery mechanism, which means you read it in a browser rather than in a repository.

The contribution rules are the real content

The rules for adding an entry are stricter than you would expect from a gallery, and each one exists for a reason. Only examples copied from production websites are accepted, so nobody can invent a straw man. Attributes that add no value must be removed, which means the example you contribute is not raw copied markup but curated markup, and the curation is what makes it readable. Any pointer that shows where the code came from must be removed, with the stated reason that the project does not want to blame anyone, so no class names, no company identifiers and no domain names survive. And only code from modern websites is allowed, which rules out markup that is bad merely because it predates a browser feature. Taken together, the rules produce a collection that is anonymised, stripped of noise, and limited to examples that are still relevant, which is a substantially different artefact from a dump of real pages. The rules also ask that you install EditorConfig before changing files, so that whitespace in the contributed files stays consistent with the rest of the repository.

Every entry follows the same three part shape

The instructions for adding a submission say to copy any other markdown file in the entries folder, and that the result should show the bad code, explain how to fix it, and then show the good code. That structure is why the site works as a teaching tool, because a wrong snippet alone teaches nothing, and a corrected snippet alone hides the mistake. The three part shape lets a reader see the problem, understand the reasoning, and then see the fix in the vocabulary they will use themselves. There is a second mechanism for the cases where the same advice keeps coming up. Because many suggestions recur, there is a file of snippets that can be included from a template, so an entry does not have to repeat a block of markup that has already been shown elsewhere on the site.

{{ snippets.sr_only }}

The snippet file is data rather than prose, which means the recurring examples live in one place and are edited once. The entries directory also needs the author of the submission recorded, and there is a separate data file listing authors by id, name and link, so each entry can credit the person who found it.

An Eleventy site with a gulp step and a screenshot script

The build is a static site generator project with a small amount of tooling around it. The site is built with Eleventy, with a configuration file at the top level and a templates directory, and there is a gulp task that handles the asset pipeline, doing concatenation, minification, clean CSS and image handling before the site itself is generated by Eleventy. The package scripts make the two step build explicit, with a script that runs the gulp build followed by the Eleventy production build, and separate scripts for each half. The development workflow is the usual Eleventy serve loop, and the environment is switched through a variable so that development and production behave differently.

npm install

npm run start

The screenshot step is the part that is specific to this project. Because each entry is about how markup renders, the site needs a picture of the result, and there is a script that takes it using Puppeteer, run while the server is still up.

npm run screenshot

The dependency list shows the era of the project, with Eleventy 0.11 and Puppeteer 2 as the pinned versions, and a small set of plugins for RSS, syntax highlighting, a progressive web app manifest and an accessibility check on the built output, which is a nice touch for a site whose subject is markup quality. There is also a Netlify configuration file, so deployment is handled by that platform, and the site is built with luxon for dates and markdown-it with anchors for the entry content.

Two licences, and you should ask which applies

There is a licence discrepancy worth flagging, because it affects anyone who copies material out of the site. The repository listing reports the licence as MIT and points to the LICENSE file at the top of the tree, while the package manifest in the repository declares the licence as ISC. The two are not the same, and the difference is not academic. MIT requires that the copyright notice and licence text travel with substantial portions of the work, while ISC is the shorter permissive text with a similar attribution requirement but different wording, and a project that ships an MIT file alongside an ISC manifest has an ambiguity that only the maintainer can resolve. For a site whose whole point is that people copy the fixed markup out of it, this is the kind of question to settle before you paste an entry into a codebase or into a company template. The repository also carries the usual EditorConfig file, a Netlify configuration and a gulp file, and it publishes no GitHub releases, so there is no tagged version of the site to point at.

An ongoing curation project rather than a product

The activity pattern is what you would expect from a collection maintained by one person as a side project. The last push was on 2026-10-07, the repository is not archived, and there are no GitHub releases, so there is no version history of the site itself beyond the commit log. The rule that only modern websites may be contributed means the collection needs periodic attention, because a page that was modern in 2023 is not necessarily a good example in 2026, and the accepted examples rot in the same way the sites they came from change. There is no version of the site described as a release, and the homepage field in the repository listing is empty because the site lives on its own domain rather than on the repository's pages. For a reader, the practical value is in the entries themselves, and the most useful way to use them is as a review checklist: when you look at a new page, the questions in HTMHell are the questions worth asking about its markup.

Editorial conclusion

HTMHell earns a place as a teaching reference and as a review checklist, because each entry pairs a real example with the corrected markup, and the rules that govern the collection make it a credible sample rather than a pile of straw men. It is not a specification and it is not a linter, and it will not tell you that your own page is wrong. Verify three things before you lean on it: that an example still applies to the browser support you target, since the collection only accepts code from modern websites, whether the accessibility fixes in the entries match the guidance your own team follows, and which licence actually covers the snippets you copy, since the repository listing reports MIT while the package manifest declares ISC. The site is published at htmhell.dev, the last push was on 2026-10-07, and the repository publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. matuzo/HTMHell on GitHub
4. README