Search for "hex to uuid" and you'll find plenty of pages that show you the format and stop there. What those pages usually skip is the part that actually causes bugs: a plain hex string, a UUID, and a GUID are not always interchangeable the moment bytes get involved, and "convert string to uuid" means two completely different things depending on what you're starting with. This guide covers all of it — the format, the terminology, the reverse conversion, the byte-order trap that quietly corrupts IDs in .NET and SQL Server, and working code you can copy into Python, JavaScript, SQL, or C#.
On this page
- What Is a Hex UUID, Exactly?
- UUID vs GUID: Is Hex to GUID Different From Hex to UUID?
- Why So Many Systems Store UUIDs as Raw Hex
- The 8-4-4-4-12 Anatomy of a UUID
- How to Convert Hex to UUID, Step by Step
- The Reverse Direction: UUID to Hex
- The Byte-Order Trap: Hex to GUID in .NET and SQL Server
- "Convert String to UUID" — Two Different Operations
- Hex to UUID in Code: Python, JavaScript, SQL, C#
- Common Mistakes When Converting Hex to UUID
- FAQ
What Is a Hex UUID, Exactly?
A UUID (Universally Unique Identifier) is a 128-bit number, standardized by RFC 4122. In its familiar form it's written as 36 characters: 32 hexadecimal digits plus 4 hyphens, grouped as 8-4-4-4-12 — for example 550e8400-e29b-41d4-a716-446655440000. A "hex uuid" is the same 128 bits with the hyphens removed: 550e8400e29b41d4a716446655440000. Nothing about the value changes — it's still the same identifier, just missing four punctuation characters that many storage formats don't need and don't want.
This distinction matters more than it sounds, because plenty of systems genuinely never see the hyphenated form. They store, log, or transmit the raw hex, and a human eventually has to turn it back into a UUID to read it, paste it into another tool, or debug it. That's the entire job our Hex to UUID converter does — hyphens in, valid UUID out — but understanding why the hex form exists in the first place makes every related question (GUID? byte order? string-to-UUID?) much easier to reason about.
UUID vs GUID: Is Hex to GUID Different From Hex to UUID?
Structurally, no. GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit value that RFC 4122 calls a UUID. Windows APIs, .NET's Guid struct, SQL Server's uniqueidentifier type, and COM all use the term GUID, but the string format — 32 hex digits in five hyphen-separated groups — is identical to a UUID. If you search "hex to guid" and land on a "hex to uuid" tool, you're in the right place; the conversion is the same operation with a different label.
Where things can diverge is not the string format but the raw byte layout some GUID implementations use internally — which is a real, separate issue covered in detail in the byte-order section below. If you're only ever working with the hyphenated string form, you can treat "GUID" and "UUID" as synonyms and move on. If you're pulling raw bytes out of a Guid.ToByteArray() call or a SQL Server uniqueidentifier column, keep reading — that's exactly the trap this guide exists to explain.
Why So Many Systems Store UUIDs as Raw Hex
The hyphenated 36-character string is convenient for humans, but it's wasteful for machines. Storing a UUID as text costs 36 bytes (or 32, without hyphens); storing the same value as raw binary costs exactly 16 bytes — the actual size of a 128-bit number. For a table with millions of rows using UUIDs as primary keys, that difference adds up fast in both storage and index size, which is why so many databases and protocols store UUIDs as plain hex or raw binary rather than as a formatted string.
| Where you'll see it | Typical storage form | What you usually need to do |
|---|---|---|
MySQL BINARY(16) columns | 16-byte binary, or hex via HEX() | Format the hex output as a UUID for display/debugging |
PostgreSQL uuid type | Native type, hyphenated on output | Usually none — Postgres already formats it |
| MongoDB legacy UUID (BSON subtype 3) | 16 raw bytes, driver-specific byte order | Convert carefully — legacy subtype byte order varies by driver |
SQL Server uniqueidentifier | 16 bytes, mixed-endian layout | Account for byte order (see below) before comparing to RFC 4122 hex |
| Redis keys, log files, debug dumps | Plain 32-character hex string | Format with a hex-to-UUID converter for readability |
| Binary protocols / gRPC payloads | 16 raw bytes on the wire | Hex-encode for logging, then convert to UUID for display |
In every one of these cases the underlying value is identical — it's a 128-bit UUID. The only thing that changes is how many characters it takes to represent it, and whether that representation includes the hyphens a human expects to see.
The 8-4-4-4-12 Anatomy of a UUID
A standard UUID splits its 32 hex digits into five groups, historically corresponding to fields from the original UUID version 1 timestamp-based design:
| Group | Length | Field name | Example |
|---|---|---|---|
| 1st | 8 hex digits (32 bits) | time_low | 550e8400 |
| 2nd | 4 hex digits (16 bits) | time_mid | e29b |
| 3rd | 4 hex digits (16 bits) | time_hi_and_version | 41d4 |
| 4th | 4 hex digits (16 bits) | clock_seq_hi_and_reserved + clock_seq_low | a716 |
| 5th | 12 hex digits (48 bits) | node | 446655440000 |
Every UUID version — v1 through v7 — uses this same 8-4-4-4-12 grouping, even though only time-based versions actually store a timestamp in those fields. That's exactly why a hex-to-UUID converter doesn't need to know which UUID version it's formatting: inserting the hyphens is purely positional, not version-aware. You can dig deeper into what those bits actually mean in a specific ID with our UUID Parser or UUID Breakdown tool.
How to Convert Hex to UUID, Step by Step
Manually, hex-to-UUID formatting is four simple steps:
- Normalize the input. Strip whitespace and any
0xprefix, and lowercase the string. - Validate. Confirm you have exactly 32 characters, all within
0-9anda-f. Anything else isn't a convertible 128-bit value. - Insert hyphens. Split into groups of 8, 4, 4, 4, and 12 characters and join with
-. - Verify. The result should match
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Run it through a UUID validator if you want extra confidence.
That's the whole algorithm — no hashing, no math, just repositioning characters. It's also exactly what happens under the hood when you paste a value into our converter, except it handles batches, flags invalid lines with their line number, and copies the result with one click.
Skip the manual formatting.
Paste one or more 32-character hex strings and get valid, RFC 4122-formatted UUIDs (or GUIDs) instantly — entirely client-side, nothing leaves your browser.
Open the Hex to UUID ConverterThe Reverse Direction: UUID to Hex
Just as often, developers need to go the other way: they have a properly formatted UUID and need the plain hex string back — typically because they're inserting it into a BINARY(16) column, matching it against a log line, or passing it to a system that expects hex without punctuation. That operation is simply the mirror image of what this whole guide covers: strip the four hyphens out of 550e8400-e29b-41d4-a716-446655440000 and you're left with 550e8400e29b41d4a716446655440000.
If that's the direction you actually need, our UUID to Hex converter does exactly this — paste a standard UUID, get the plain hex string, no manual find-and-replace required. Between the two tools, hex-to-UUID and UUID-to-hex cover the full round trip in either direction.
The Byte-Order Trap: Hex to GUID in .NET and SQL Server
This is the part most "hex to guid" guides skip entirely, and it's the one that actually causes production bugs. RFC 4122 defines a UUID's byte layout as big-endian throughout — the bytes appear in the same left-to-right order as the hex digits in the string. Java's UUID, Python's uuid module, and most non-Microsoft systems follow this consistently.
.NET's Guid struct does not. Internally — and in the byte array returned by Guid.ToByteArray() or accepted by new Guid(byte[]) — the first three groups (the 4-byte, 2-byte, and 2-byte fields corresponding to time_low, time_mid, and time_hi_and_version) are stored in little-endian order, meaning those bytes are reversed relative to how they read in the string. The last two groups (clock sequence and node, 8 bytes total) are stored in the same order they appear in the string. SQL Server's uniqueidentifier type follows this same mixed-endian layout internally, which is also why sorting a table by a uniqueidentifier column doesn't produce the same order you'd get sorting the equivalent strings alphabetically.
In practice: if you take raw 16 bytes from a Java, Python, or network-order source and feed them straight into new Guid(bytes) in C#, you'll get a GUID whose string representation does not match what you expected — even though every byte value is technically "correct." The fix is to reverse the byte order of the first three groups (4 bytes, then 2 bytes, then 2 bytes) before constructing the Guid, and reverse it back before sending bytes the other way.
If you only ever work with the hyphenated string form — copying, pasting, and formatting text — none of this affects you, and hex to UUID / hex to GUID behave identically. This trap only appears once raw bytes are involved: deserializing a Guid from a byte array, reading a uniqueidentifier column at the byte level, or interoperating between a .NET service and a non-.NET one that both claim to be sending "the same GUID."
"Convert String to UUID" — Two Different Operations
This search phrase is genuinely ambiguous, and the two interpretations lead to completely different tools:
- Your string is already 32 hex characters. In that case "convert string to uuid" just means the formatting operation this whole guide covers — insert the hyphens with the hex to UUID converter above.
- Your string is arbitrary text — a filename, a URL, an email address, a username — and you want the same input to always produce the same UUID. That's not formatting; it's name-based UUID generation, defined by RFC 4122 as UUID versions 3 and 5. You supply a namespace (a fixed reference UUID) and a name (your string); the algorithm hashes them together — MD5 for v3, SHA-1 for v5 — and the result is a deterministic UUID that's identical every time you feed it the same namespace and name.
If you need the second kind, use the UUID v5 Generator (SHA-1 based, the modern recommendation) or the UUID v3 Generator (MD5 based, kept for compatibility with older systems). Neither of these accepts arbitrary hex directly — they hash whatever string you give them — so don't confuse them with the hex-to-UUID formatting tool covered earlier in this guide. Choosing the wrong one is the single most common mix-up in this whole topic area.
Hex to UUID in Code: Python, JavaScript, SQL, C#
If you're automating this rather than converting one-off values, here's the same hex-to-UUID conversion in four common environments.
Python
import uuid
hex_string = "550e8400e29b41d4a716446655440000"
u = uuid.UUID(hex=hex_string)
print(u)
# 550e8400-e29b-41d4-a716-446655440000
# Reverse (uuid to hex):
print(u.hex)
# 550e8400e29b41d4a716446655440000
JavaScript
function hexToUuid(hex) {
const h = hex.replace(/[^0-9a-f]/gi, '').toLowerCase();
return `${h.slice(0,8)}-${h.slice(8,12)}-${h.slice(12,16)}-${h.slice(16,20)}-${h.slice(20)}`;
}
hexToUuid("550e8400e29b41d4a716446655440000");
// "550e8400-e29b-41d4-a716-446655440000"
// Reverse (uuid to hex):
const uuidToHex = (uuid) => uuid.replace(/-/g, '');
SQL (MySQL 8.0+)
-- Hex to UUID
SELECT BIN_TO_UUID(UNHEX('550e8400e29b41d4a716446655440000'));
-- 550e8400-e29b-41d4-a716-446655440000
-- Reverse: UUID to hex
SELECT HEX(UUID_TO_BIN('550e8400-e29b-41d4-a716-446655440000'));
-- 550E8400E29B41D4A716446655440000
C# (.NET)
// Hex to GUID — remember the byte-order note above
byte[] bytes = Convert.FromHexString("550e8400e29b41d4a716446655440000");
Guid g = new Guid(bytes);
Console.WriteLine(g);
// Byte order for the first three groups differs from RFC 4122 —
// verify against your source system if bytes (not just strings) are shared.
// If you only need the string form, skip byte handling entirely:
string hex = "550e8400e29b41d4a716446655440000";
Guid g2 = Guid.Parse(string.Format("{0}-{1}-{2}-{3}-{4}",
hex.Substring(0,8), hex.Substring(8,4), hex.Substring(12,4),
hex.Substring(16,4), hex.Substring(20,12)));
Notice the C# example splits into two cases deliberately: parsing the string form is always safe, because Guid.Parse reads the hyphenated string in the same order RFC 4122 expects. It's specifically the raw byte array path — new Guid(byte[]) — where the endianness mismatch from the previous section can bite you.
Common Mistakes When Converting Hex to UUID
- Wrong length. A hex string that's 30, 31, 33, or 34 characters isn't a valid 128-bit value and can't be formatted into a real UUID — check for a stray character or a truncated copy-paste before assuming the converter is broken.
- Non-hex characters. Anything outside
0-9a-f(including a leftover0xprefix, curly braces from a Microsoft-style GUID literal like{550e8400-...}, or stray whitespace) will fail validation until it's cleaned up. - Confusing formatting with hashing. As covered above, "convert string to uuid" for an arbitrary (non-hex) string needs a name-based generator, not a hex formatter.
- Assuming byte order always matches the string. Fine for pure string-to-string work; not safe once raw bytes cross between .NET/SQL Server and almost anything else, as covered in the byte-order section.
- Case sensitivity assumptions. UUIDs are conventionally lowercase, but they're case-insensitive by spec —
550E8400...and550e8400...represent the same value. A good converter normalizes case rather than rejecting uppercase input.
Frequently Asked Questions
What's the difference between hex to UUID and hex to GUID?
None, structurally. GUID is Microsoft's name for the same 128-bit identifier RFC 4122 calls a UUID, and the string format is identical. The only place they can diverge is raw byte layout, covered in the byte-order section above.
How do I convert a string to a UUID?
If the string is 32 hex characters, use the hex to UUID converter to insert the hyphens. If it's an arbitrary string, use the UUID v5 Generator to hash it against a namespace instead.
How do I convert a UUID back to hex?
Strip the hyphens, or use the UUID to hex converter to do it automatically — it's the exact reverse of the hex-to-UUID conversion this guide covers.
Why does hex to GUID sometimes produce a different-looking value in .NET or SQL Server?
Because those systems store the first three groups of a GUID in little-endian byte order internally, while RFC 4122's byte layout is big-endian throughout. It only matters when raw bytes — not strings — are shared between systems.
Can I convert multiple hex strings to UUIDs at once?
Yes — paste one hex string per line into the converter above and every valid line converts at once, with invalid lines flagged individually.
Is every 32-character hex string a valid UUID?
Structurally, any 32 hex digits can be formatted as a UUID-shaped string. Whether it's a valid UUID under a specific version's rules depends on its version and variant bits — check with a UUID version checker if that distinction matters for your use case.
Which UUID version should I use for new IDs, rather than converting existing hex?
UUID v4 (random) for general-purpose IDs, or UUID v7 for sortable, time-ordered database keys. Reach for UUID v4 or UUID v7 generators rather than deriving new IDs from hex at all.
Ready to convert?
Paste your hex string, get a valid UUID or GUID instantly, and use the reverse converter whenever you need to go back to plain hex — both run entirely in your browser.
Open the Hex to UUID / Hex to GUID ConverterWorking with UUIDs beyond this one conversion? Our full UUID Generator toolkit covers every version (v1 through v7), validation, parsing, and format conversions including UUID to Base64 and UUID to binary — the same 128-bit value, in every representation you're likely to run into.