Skip to main content

How to Extract UUIDs From Logs and Text Without Losing Your Mind

Pull every UUID out of a log file or pasted text, dedupe the matches, and export a clean list. A practical guide to the 8-4-4-4-12 hex pattern and local parsing.

Published By Li Lei
#uuid #logs #developer-tools #text-parsing

How to Extract UUIDs From Logs and Text Without Losing Your Mind

A UUID is one of those values you stop reading the moment your eyes land on it. Thirty-two hex digits broken up by four dashes, something like 9f1c2b7e-4a3d-4c11-8e0a-2f6b9d4c7a01, repeated a few hundred times across a log file. When you actually need those IDs out of the noise, scrolling and copying by hand is the wrong approach. You want every match pulled at once, the duplicates collapsed, and a clean list you can paste somewhere useful.

That is the whole job of UUID Extractor. You drop in a log, a SQL result, a copied web page, or a pile of support notes, and it hands back a deduplicated table of just the IDs. No upload, no round trip to a server, no manual cleanup.

What a UUID Actually Looks Like

The pattern is fixed, which is exactly why a machine can find them and you can trust the matches. A UUID is 32 hexadecimal digits arranged in an 8-4-4-4-12 dash pattern: eight characters, a dash, four, a dash, four, a dash, four, a dash, and twelve to finish. Hex means the only legal characters are 0 through 9 and a through f (case does not matter). Total length with the dashes is 36 characters.

Because the shape is so rigid, a scanner can sweep through any blob of text and catch every value that fits, while ignoring the log timestamps, the JSON keys, and the prose wrapped around them. That same rigidity is why the extractor can flag near-misses: a 30-character hex string or a hash that happens to look ID-shaped gets caught, then marked invalid so you know the pattern grabbed something that is not really an identifier.

Why You End Up Doing This

The reasons are all variations on the same theme: a UUID is the join key between systems, and you need a batch of them lifted out of one place to use in another.

  • Pulling trace and request IDs from logs. A single failed request leaves a trail of log lines, each tagged with the same correlation ID. Pull all the IDs from an error window and you have the exact set to grep for, query against, or hand to whoever owns the downstream service.
  • Collecting record IDs for a query. You have a stack tickets, an email thread, or a spreadsheet column where someone pasted the affected rows. Extract the IDs, dedupe them, and you have a ready WHERE id IN (...) list.
  • Auditing what got touched. A migration script printed every row it modified. Extract the IDs, sort them, and diff against what you expected to change.

In all three cases the input is messy and the output needs to be clean, deduplicated, and shaped for the next tool.

A Worked Example

Here is a trimmed application log. Notice the same request ID shows up on three lines, and there is a stray user ID in the mix:

2026-06-13T09:14:02Z INFO  req=9f1c2b7e-4a3d-4c11-8e0a-2f6b9d4c7a01 user=3c5d8a90-1b2e-4f67-9a0b-cd1e2f3a4b5c start
2026-06-13T09:14:02Z DEBUG req=9f1c2b7e-4a3d-4c11-8e0a-2f6b9d4c7a01 cache miss
2026-06-13T09:14:03Z WARN  req=9f1c2b7e-4a3d-4c11-8e0a-2f6b9d4c7a01 retry 1
2026-06-13T09:14:05Z ERROR req=7e2a1f4b-9c3d-4a8e-b1f0-6d5c4b3a2e1f timeout

Paste that in and the extractor walks every line, grabs the four UUIDs, and collapses the three identical request IDs into one. With dedupe on, the output is:

9f1c2b7e-4a3d-4c11-8e0a-2f6b9d4c7a01
3c5d8a90-1b2e-4f67-9a0b-cd1e2f3a4b5c
7e2a1f4b-9c3d-4a8e-b1f0-6d5c4b3a2e1f

Three unique IDs out of a dozen log lines, with the timestamps and log levels stripped away. Switch the output format and the same three values come out as a JSON array, a SQL IN clause, or a TypeScript union, so you skip the tedious step of hand-adding quotes and commas.

Dedup Is the Part You Care About

Raw extraction is easy; the value is in what comes after. Logs repeat the same correlation ID on every line of a transaction, so a naive grab gives you the same UUID twenty times over. The extractor keeps unique rows by default, which means the count it reports is the count of distinct things, not the count of mentions. If you would rather see the noise, you can turn dedup off and keep every occurrence with its original line number, which is handy when you need to know how many times an ID appeared, not just whether it did.

One gotcha worth naming: text copied from a web page or a rendered table often carries hidden whitespace and zero-width characters. Two IDs that look identical can fail to dedupe because one has an invisible trailing space. Normalizing before you dedupe fixes this, and when the source is especially dirty it is worth running it through the dedicated UUID Deduplicator for a stricter pass.

Everything Stays on Your Machine

I reach for this constantly when I am triaging an incident, and the part that matters most to me is that the log never leaves the tab. Production logs are full of customer record IDs, session tokens, and internal identifiers that I have no business pasting into some random web service. Here the parsing, validation, dedupe, and download all run in the browser. When I upload a text file, it is read locally through the File API and nothing gets shipped to a server. That is the difference between a tool I can use on real incident data and one I keep at arm's length.

A practical note on size: the input is meant to be an app log, a SQL result, or a pasted payload, comfortably within a few megabytes. If you are staring at a multi-gigabyte archive, grep the relevant lines locally first, then bring that slice here for the cleanup and export.

When to Keep the Invalid Rows

It is tempting to throw away anything that does not validate, but the rejects are often the most interesting part. An invalid catch is usually a hex string of the wrong length or a hash that wandered into the 8-4-4-4-12 neighborhood without being a real ID. Keeping those rows visible tells you what the pattern picked up that you did not intend, which is exactly the signal you want when you are about to feed a list into an import or a query. Validation confirms shape, not existence: a perfectly formed UUID still does not prove the record behind it is real, so treat the clean list as a starting point, not a guarantee.

Once the list is clean, deduped, and validated, you export the format you need and move on. The messy log goes back to being noise, and you walk away with the three IDs that actually mattered.

Made by Toolora · Updated 2026-06-13