Find every identifier in a codebase, decode the time inside it, and refuse the ones that cannot be named
UUID · ULID · NanoID · MongoDB ObjectId · Snowflake
Useful? A star is how other developers find it — ★ GitHub · letools.dev/tools/ids-le
Point it at a file or a tree. For every identifier it finds it reports the kind, the raw text, where it is — line, column, and the document's own key path — whether it is valid, and, where the identifier embeds a timestamp, that timestamp as an ISO-8601 UTC string.
$ ids-le ids.json
ids.json:3:12 uuid v4 f47ac10b-58cc-4372-a567-0e02b2c3d479
ids.json:4:19 uuid v7 019ff344-cc00-7abc-8def-0123456789ab 2026-08-12T00:00:00.000Z
ids.json:7:14 ulid 01KZSM9K00ABCDEFGH12345678 2026-08-12T00:00:00.000Z
ids.json:8:16 nanoid V1StGXR8_Z5jdHi6B-myT
ids.json:11:15 objectid 6a7bb780a1b2c3d4e5f60718 2026-08-12T00:00:00.000Z
ids.json:13:30 snowflake 1536886938009600000 2026-08-12T00:00:00.000Z
ids.json:14:19 refused (nil_or_max) 00000000-0000-0000-0000-000000000000 — the nil UUID: 128 zero bits, which RFC 9562 defines as naming nothing
6 identifiers in 1 file
1 run refusedThat is stderr. stdout carried the same seven rows as one JSON line, which is what a pipeline reads:
{
"schema": 1,
"file": "ids.json",
"format": "json",
"ids": [
{
"kind": "uuid",
"value": "019ff344-cc00-7abc-8def-0123456789ab",
"line": 4,
"column": 19,
"key": "service.requestId",
"valid": true,
"version": 7,
"variant": "rfc4122",
"timestamp": "2026-08-12T00:00:00.000Z"
},
{
"kind": "uuid",
"value": "00000000-0000-0000-0000-000000000000",
"line": 14,
"column": 19,
"key": "placeholder",
"valid": false,
"refused": "nil_or_max",
"detail": "the nil UUID: 128 zero bits, which RFC 9562 defines as naming nothing"
}
],
"diagnostics": [],
"summary": { "ids": 6, "refused": 1 }
}kind is always present, and null where naming a kind is exactly what was
refused — a reader has to be able to tell "no kind" from "field missing".
Columns are counted in UTF-16 code units, so they match what an editor
shows you.
A tool that answers confidently and wrongly is worse than one that stops and names what it needs. So every run this crate will not name is a row in the report with a reason — never a dropped row, never a silent guess.
| Reason | What it means |
|---|---|
ambiguous_kind |
Two or more schemes fit and nothing in the document chooses between them. |
malformed |
The right shape, and validation failed. |
nil_or_max |
The nil or max UUID: structurally perfect, and RFC 9562 says it names nothing. |
version_claim_mismatch |
A UUID claims v4 — 122 random bits — and the bytes are plainly not random. Both are reported; neither is resolved. |
timestamp_implausible |
A decode landed before 1990 or more than a year out. The decode comes with the flag. |
Some are worth spelling out, because they are the cases a regex gets confidently wrong:
5d41402abc4b2a76b9719d911017c592is an unhyphenated UUID and an MD5 digest. Nothing in a document separates them, so nothing here picks.6a7bb780a1b2c3d4e5f60718is 24 hex characters. Under_idit is an ObjectId minted on 2026-08-12. Underchecksum, or in prose, it is refused — an ObjectId's whole specification is 24 hex characters, so a truncated SHA-1 fits it exactly and only the document can tell them apart.1536886938009600000underchannel_idis a Discord Snowflake at 2026-08-12. Under a bareuser_idit is refused, because the Twitter epoch fits too and the document does not say which. Underpopulationit is not a finding at all.
The full table, and the boundaries the tool holds itself to, are in
crate/SPEC.md.
cargo install ids-leOr from a checkout:
git clone https://github.com/nolindnaidoo/ids-le
cargo install --path ids-le/crateNeeds Rust 1.88+, and nothing else. No runtime, no network, nothing written.
ids-le src/ # a tree
ids-le --kind uuid src/ # one scheme
ids-le --strict src/ # fail on anything that could not be named
ids-le --hidden src/ # include .env
cat config.yaml | ids-le --stdin --format yamlstdout is protocol — one JSON object per line, one line per file. stderr is
for you. There is no --json flag: one mode, and the human summary is a
projection of the same reports so the two cannot drift.
| Flag | Effect |
|---|---|
--kind <kind> |
Report only uuid, ulid, nanoid, objectid or snowflake. A view over the report, applied after the analysis — the unfiltered run is the complete one. |
--format <format> |
Force a format. An unknown name reads the text directly rather than failing. |
--strict |
Exit 2 on any refusal or unreadable text file. |
--stdin |
Read one document from stdin. Takes no file arguments. |
--hidden |
Walk hidden files and directories — which is where .env lives. |
--no-ignore |
Walk files .gitignore excludes. |
| Kind | Shape | Decoded time | Extra fields |
|---|---|---|---|
uuid |
36 characters, 8-4-4-4-12, hex |
v1, v6, v7 | version, variant |
ulid |
26 characters, Crockford base32 | always (48-bit Unix ms) | — |
nanoid |
21 characters, A-Za-z0-9_- |
never — a NanoID has no clock | — |
objectid |
24 hex characters, under a key naming an id | always (32-bit Unix seconds) | — |
snowflake |
17–19 digits, under a key naming an id | always (top 42 bits + an epoch) | — |
Two of those kinds need the document's permission. An ObjectId is 24
hex characters and a Snowflake is a large integer; neither carries a
version, a variant, a checksum or a restricted alphabet, so neither run
can say on its own what it is — a truncated git hash is a structurally
perfect ObjectId, and a byte count is a structurally perfect Snowflake.
Both are named only where the field's own name ends in id (_id,
userId, USER-ID, $oid), and refused as ambiguous_kind otherwise.
In a plain-text file, which has no keys at all, neither is ever named.
All eight UUID versions RFC 9562 defines are recognised, and all four
variants — ncs, rfc4122, microsoft, future — are reported. A version
is only reported under the RFC variant, because in any other layout those
four bits are not a version field.
This is the part nobody wants to write twice. Six of these carry a clock, in six unrelated bit layouts, over four different epochs — one of which starts in 1582:
| Scheme | Where the time is | Epoch |
|---|---|---|
| UUID v1 | 60 bits of 100-nanosecond intervals, low field first | 1582-10-15 |
| UUID v6 | the same ticks, reordered so they sort | 1582-10-15 |
| UUID v7 | 48 bits of milliseconds, at the front | Unix |
| ULID | the first ten Crockford characters, 48 bits | Unix |
| ObjectId | the leading four bytes, in seconds | Unix |
| Snowflake | the top 42 bits | Twitter (2010-11-04) or Discord (2015-01-01) |
Every one comes back as the same ISO-8601 UTC string, milliseconds always present. UUID v2 is named and not decoded: its clock has its low 32 bits overwritten by a POSIX uid, so it resolves to roughly seven minutes and is not the same claim.
A decode that lands before 1990 or more than a year from now is refused as
timestamp_implausible — and the decode is on the row next to the flag,
because a refusal that hides its evidence is a verdict a reader cannot check.
Taken from ids-le --help, which is the authority.
| Option | What it does |
|---|---|
--kind <kind> |
Report only one of uuid, ulid, nanoid, objectid, snowflake |
--format <format> |
Force a format instead of inferring it from the file name; an unknown name falls back to a text read rather than failing |
--strict |
Exit 2 if anything was refused or any file could not be read, rather than reporting it and carrying on |
--stdin |
Read one document from stdin |
--hidden |
Walk hidden files and directories too |
--no-ignore |
Walk files that .gitignore excludes |
A filter narrows what this tool claims, never what it declined to claim:
a refusal survives --kind.
Follow grep, so a shell can branch on them:
| Code | Meaning |
|---|---|
0 |
Identifiers found |
1 |
None found — an answer, not an error |
2 |
The question was malformed, or a scan gave up part way |
A refusal does not move the exit code. Refusing is the tool working;
--strict is how a pipeline turns it into a failure. A binary file — a NUL
byte in its first 8 KiB, ripgrep's own test — is never a text candidate: no
report line, counted on stderr, and it never fails the run.
JSON (and JSONC), YAML, TOML, INI (.properties), dotenv, CSV and TSV
give each finding a key path — service.requestId,
documents.[0]._id, discord.channel_id. Everything else is read as text:
the same runs, in the same places, without the key. That is why you can
point this at a repository nobody has described to it and get an answer out
of the .md, the .sql and the .tf as well as the config.
The key path is evidence, not decoration. ObjectId and Snowflake are named
only under a field the document calls an id, so a run that is named in the
.json comes back ambiguous_kind in the .md beside it — same row, same
position, same decode, and a reason instead of a name.
ids-le mcpSpeaks the Model Context Protocol on stdio and offers two tools:
extract_ids, which reads a document handed to it and touches no filesystem,
and ids_le_scan, which reads files and directories. Both return one
envelope — { ok, data, diagnostics, meta } — where ok means the check
ran, never that the answer was yes.
Refusals reach the agent as rows, exactly as they reach the terminal. An agent that received only the identifiers this crate was willing to name would conclude a document was clean when what actually happened is that nothing in it could be named.
It does not generate identifiers, rewrite them, redact them, or decide
whether one should be where it is. It reads; nothing is written. It never
touches the network, and it verifies nothing against a database or an API.
Full list in crate/SPEC.md, "Non-goals".
| What | Where |
|---|---|
| What the tool is allowed to say — scope, output contract, refusals, non-goals | crate/SPEC.md |
| How the code is written and held together — architecture, invariants, the gates | crate/AGENTS.md |
| The crate's own front page | crate/README.md |
| What changed | CHANGELOG.md · crate/CHANGELOG.md |
| The tool's page, and the other fifteen | letools.dev/tools/ids-le |
Sixteen single-purpose tools for the work in front of every model. Each ships a Rust CLI and an MCP server. One page: letools.dev
Get it out
- String-LE — Extract every string in a codebase, with its position, so a person can read them
- Numbers-LE — Extract every hardcoded number in a codebase, so a person can check them
- Units-LE — Extract every quantity with its unit, normalized, and refuse the ambiguous ones by name
- Dates-LE — Extract every date and timestamp, and the exact instant each one resolves to
- IDs-LE — Extract every UUID, ULID, NanoID, ObjectId and Snowflake, and decode the time inside
- IPs-LE — Extract every IP address, CIDR block and MAC, normalized and classified by scope
- URLs-LE — Extract every URL in a codebase, with its protocol and exact position
- Paths-LE — Extract every file path in a codebase, and say whether it still points at anything
- Colors-LE — Extract every color in a codebase, and say which ones are not in your palette
Check it
- Regex-LE — Find every regex in a codebase, and report which can be driven into catastrophic backtracking
- Versions-LE — Find where one dependency is constrained differently across a repository's manifests
- i18n-LE — Identify the i18n library a project uses, then audit its catalogs by that library's rules
- Scrape-LE — Check whether a page is scrapeable before the scraper is written, and say when it cannot tell
Guard it
- Secrets-LE — Find hardcoded credentials in a codebase, and never print one into the report
- EnvSync-LE — Compare the dotenv files in a tree, and say which keys are missing from which
- Unicode-LE — Find the Unicode that hides meaning — bidi controls, invisibles, homoglyphs, mixed scripts
Each stands on its own: no shared crate, no published core. Where two of them agree, it is because the same answer was right twice.
Contact — nolindnaidoo.com · GitHub · LinkedIn
Rust — pixelcoords and pixelactions are one loop: pixelcoords answers where, pixelactions acts there. Their own tools, their own voice — not part of the LE family.
- pixelcoords — Freeze your screen, mark regions, get pixel-exact coordinates and crops pixelcoords.dev · crates.io · docs.rs
- pixelactions — Consume human-verified coordinates, perform the interaction, confirm it landed pixelactions.dev · crates.io · docs.rs
MIT © nolindnaidoo
