Peng.lyBlog

Wikipedia dropped this UUID in 2014. Now it's everywhere

Wikipedia's old example UUID is in 300,000 GitHub files, nearly all added since 2025. Which AI models hand it out, and the app that signed logins with it.

550e8400-e29b-41d4-a716-446655440000

Recognise it? GitHub’s code search reckons it’s in about 303,000 files. That’s twice as many as 123e4567-e89b-12d3-a456-426614174000, the other example UUID you’ve probably seen, and more than any other I tried apart from the all-zeros one. A fresh random one turns up in 0. One app with 2,000 stars even used it as the key that signs its logins.

It was Wikipedia’s example. The UUID article used it from 2006 until 2014, when someone swapped it for the 123e4567 one, which MDN uses too. It isn’t only Wikipedia’s (an OVSDB RFC and Rust’s uuid crate use it as well), but it’s the sort of thing you’d expect to be quietly fading out by now. Wikipedia isn’t helping, mind. Someone put it back on the page in 2023 for the URN example, and 123e4567 came off in 2024.

Nearly all of it is new

I picked 150 repos at random that have it and went back through each file’s history to the commit that added it. 147 of them added it in 2025 or 2026, and 113 this year alone.

Issues and PRs show when it happened:

GitHub issues and PRs mentioning each UUID, by month

These are GitHub’s issue search counts for each full string, by the month the issue or PR was opened, from January 2024 to October 2026.

The numbers
Month550e8400123e4567
Jan 2497
Feb 2410
Mar 2426
Apr 24613
May 241011
Jun 24817
Jul 241110
Aug 24617
Sep 24718
Oct 241220
Nov 241935
Dec 241641
Jan 25837
Feb 253468
Mar 252637
Apr 252648
May 255148
Jun 256689
Jul 2591111
Aug 25139109
Sep 25132121
Oct 25256117
Nov 25286135
Dec 25343105
Jan 26418130
Feb 26441112
Mar 2647098
Apr 26416107
May 2634480
Jun 26313103
Jul 26281108
Aug 26314127
Sep 26299108
Oct 26254105

Through 2024 it trailed 123e4567. Then it crossed over in mid-2025, peaked in March this year at 470 a month, and has nearly halved since. Something started handing it out again.

So I asked them

I gave Claude and Codex the same three requests, three times each: an example UUID, a JSON order object with a UUID id, and a Python test fixture with a hardcoded UUID. That’s nine answers per model, on 3 November, with Codex running gpt-5.6-sol:

ModelWhat it gave me
Claude Sonnet 4.5550e8400 8 times, something else once
Claude Haiku 4.5550e8400 all 9 times
Codex550e8400 for the examples, 123e4567 for tests
Claude Opus 5.5a made-up 3f... one all 9 times
Claude Sonnet 5.5a made-up 3f... one 6 times, f47ac10b... 3 times
Claude Haiku 5.5a made-up 3f... one 5 times, 123e4567 3 times

The 4.5 models hand out Wikipedia’s old one nearly every time. But the curve crossed over before either of them came out, so I’d guess the Claude 4 models had the habit too. Sonnet 4 has been retired, so I can’t ask it. Of the 150 commits I dated, 22 had Claude Code’s co-author line on them, against 12 of 150 for 123e4567. That’s a lean rather than proof, since Claude Code adds that line by default, so its work is easy to spot and other tools’ might not be.

Why that one and not 123e4567, I can’t tell you. It wasn’t the more common of the two in code before 2025, so it’s not just that there was more of it to learn from. Its return to Wikipedia in 2023 might have helped, but that’s a guess.

Claude’s moved on

The newer Claude models never gave me 550e8400 at all. They mostly make one up, and they make up much the same one. 20 of their 27 answers started with 3f, and 12 with exactly 3f2b8c1e or 3f8a2c1e:

3f2b8c1e-9a4d-4e7b-8c21-5d6f0a9b7e43
3f2b8c1e-9a4d-4e7b-8e2a-6c5d0b1a9f47
3f2b8c1e-7a4d-4e9b-9c15-2d6f0a8b4e71
3f8a2c1e-7b4d-4e9a-a6c2-91d5e0b7f348

The start sticks, more or less, and the end wanders off. The first 18 characters of the top one, 3f2b8c1e-9a4d-4e7b, are already in about 370 files on GitHub, across at least 124 repos. I dated 50 of those, and every one added it in 2026, 21 of them with Claude Code’s co-author line.

So if you find a 550e8400 in a repo you’ve inherited, it was probably written in the last couple of years, quite possibly by a 4.5 model or Codex, and a 3f2b8c1e-9a4d points at a newer Claude. More of a tell than I expected a UUID to be.

The other one I’d learn is 3fa85f64-5717-4562-b3fc-2c963f66afa6, in about 40,000 files. It comes from Swagger UI’s example generator, which fills in example requests in API docs, so if it turns up in your logs, it’s usually someone sending the example from your docs as it was.

When the example is the secret

Aix-DB, an app for asking your database questions in plain English, used this for its login tokens:

common/token_decorator.py
os.getenv("JWT_SECRET_KEY", "550e8400-e29b-41d4-a716-446655440000")

From release 1.2.0 its example config suggested this as the key, and from 1.2.2 the code fell back to it whenever JWT_SECRET_KEY wasn’t set, which its Docker Compose file didn’t do. So a default install signed its tokens with a key that’s in 300,000 public files, and anyone could have made their own token with the admin role in it.

An automated security PR took the fallback out on 10 October, and the Compose file now refuses to start without a key. There hasn’t been a release since, though, so 1.2.4 is still the latest. I found a couple more, in tiny repos and still live, so no names.

Opus 5.5’s own answer, when I asked it for an example UUID, came with a warning:

I made it up by hand rather than generating it, so don’t use it anywhere uniqueness matters - for that, run uuidgen.

Fair enough, coming from the family that’s spreading 3f2b8c1e round GitHub.