i-hate-regex: a regex cheatsheet that draws what the syntax means

A cheat sheet aimed at people who find regex unreadable

The tagline under the logo is the whole thesis: don't just use, understand. The site presents itself as a regex cheatsheet for the haters, which is a friendlier way of saying it was built for people who keep getting pasted a regular expression and have no idea what any part of it does.

The answer to that problem is visual rather than textual. Expressions render as railroad diagrams in the browser, with no embed server involved, and hovering over any part of an expression explains what that part does in plain English. Alongside that there is a testing area with live highlighting of matched strings, code highlighting and validation, and export of any diagram as SVG or PNG.

The repository is TypeScript, MIT-style open, with 4561 stars and 318 forks across 41 open issues. It is not archived, and the last push was on 2026-09-10, so the code is being worked on. The homepage is iHateRegex.io, and there is a Telegram community linked from the README.

The v2 rebuild replaced Nuxt with TanStack Start and a database

The most useful line in the README is a warning. Version 2 was rebuilt from the ground up on TypeScript, TanStack Start and PostgreSQL, and the original Nuxt version survives on a `v1` branch.

That explains an oddity in the repository metadata. The topics list still reads nuxt, regex, tailwindcss and vue, which describes the version the project used to be rather than the version it is now. If you are deciding whether to contribute, the README is the more current document of the two.

The repository is a pnpm monorepo with a short tree:

apps/
└── web/                         # TanStack Start app and PostgreSQL migrations
└── packages/
    └── regex-railroad-diagram/      # Browser-only TypeScript diagram renderer

Rendering is deliberately browser-only, which keeps the diagram renderer independent of the web app. That separation matters for a diagram library: it means the drawing code has no server dependency to negotiate, and it explains why `pnpm diagram:dev` exists as its own command to run the package demo on its own. The diagrams themselves are credited to regexper.

A PostgreSQL backend is the other consequence of v2. Adding user accounts means adding somewhere to put them, and the privacy design in the README follows from that choice.

Setting it up needs Node 22.12, pnpm 10 and a local Postgres

The requirements are specific: Node.js 22.12 or newer, pnpm 10 or newer, and PostgreSQL. The root package.json pins the package manager at [email protected] and declares the Node engine constraint, so pnpm will complain rather than fail quietly on an older runtime.

The setup sequence from the README, once the repo is cloned:

pnpm install

createdb ihateregex_next
cp apps/web/.env.example apps/web/.env.local
pnpm db:migrate   # apply database migrations
pnpm dev          # serve at http://127.0.0.1:3000

Three environment values have to be set in `.env.local`: `DATABASE_URL`, `BETTER_AUTH_URL`, and a random `BETTER_AUTH_SECRET` of at least 32 characters. Those names make the auth stack legible: this is Better Auth, and the secret length requirement is theirs rather than the project's own invention.

Beyond that the scripts are unremarkable in a good way. `pnpm build` builds both workspace packages, `pnpm check` type-checks every workspace package, and `pnpm start` runs the production server. The root scripts chain the diagram package build before the web app, so a first `pnpm dev` compiles the renderer before serving.

Contributing a regex is two files

The contribution path is short enough that it does not need much explaining, which is likely the point. Every expression lives in one JSON file at `apps/web/src/content/regexes.json`, and a longer markdown description sits next to it at `apps/web/src/content/regex/<regex-id>.md`.

The JSON shape is worth looking at, because the schema is the documentation:

{
    "id": "username",
    "title": "username",
    "tagline": "match a username",
    "description": "Alphanumeric string that may include _ and - having a length of 3 to 16 characters.",
    "regex": "^[a-z0-9_-]{3,15}$",
    "flag": "gm",
    "matchText": [
        "lorem",
        "ipsum",
        "gr3at",
        "john doe",
        "johnny"
    ],
    "tags": ["name", "slug"]
}

A few fields carry more weight than their names suggest. `description` doubles as the meta description, so it is doing SEO work as well as explanatory work. `matchText` is an array of strings shown in the testing area, which means the sample strings are part of the teaching: `john doe` and `johnny` are there to show a reader that a 3-to-15 character rule rejects or accepts specific cases. The `id` doubles as the slug and has to be URL-safe with no spaces.

There is also a `patches/` directory in the tree, which is a small sign of friction being dealt with in a dependency tree rather than ignored.

Saved regexes stay private until you publish them

The v2 feature list adds user accounts with private saved regexes, a playground for building your own expressions, and publishing to a community page with a stable link.

The privacy model is spelled out and is the part most worth copying. New saves belong to the signed-in user and are private. Publishing a regex creates a public page, and the owner can unpublish at any time. The URL contains only an opaque database ID, never the regex itself in a query string.

That last detail is a deliberate choice rather than an accident. Putting a pattern in a query string means it ends up in server logs, in shared links, and in anybody's copy-paste buffer, and regular expressions are more revealing than people expect: one matching a national identifier or an internal host format discloses the shape of the data it was written for.

The playground is also the answer to a fair criticism of any static cheat sheet, which is that the expressions are somebody else's opinions about what a good pattern looks like. Being able to test your own against the same diagram renderer changes that.

Where the release history stops and the README takes over

There is a single tagged release, v0.1.2 from 2020-10-11, and its notes are small: a Telegram community link, a donate page, and a sidebar spacing fix. Against a repository pushed as recently as 2026-09-10, that gap says releases are not how this project ships. The README is the place where the current state lives.

That is not a criticism so much as a shape. A content site with a community contribution model does not need semver, because the interesting artefact is the corpus of expressions rather than an API someone depends on. It does mean you should judge activity by commit recency rather than by the version number, and by whether your patterns still match how the current renderer draws them.

The README itself is unusually honest about its own history, naming the Nuxt predecessor, pointing at the `v1` branch, crediting regexper for the diagram rendering, and linking OpenCollective for funding. For a project that began as a meme-adjacent name and turned into a genuinely useful reference, that combination of plain writing and working tool is the main thing to take away.

Editorial conclusion

The thing this project does that a regex tester does not is explain, and that is worth the whole effort for anyone who has stared at a lookahead group and given up. Railroad diagrams turn a character class into a picture you can read without training, and the hover explanations fill in what the picture leaves implicit. It is also a rewrite in progress in a way worth naming plainly: the topics still advertise the Nuxt stack the v2 rebuild replaced, and the only tagged release is v0.1.2 from 2020, so judge the current software by the README rather than by the release history. Start by reading one entry, then use the playground to build your own and publish it.

Frequently asked questions

Official sources

1. geongeorge/i-hate-regex on GitHub
2. Issues
3. Project website
4. README
5. Releases