What is a UUID Without Hyphens
A canonical UUID is 36 characters because 32 hex digits are separated by four hyphens at fixed positions. Those hyphens are punctuation, not data — they exist so humans can read the 8-4-4-4-12 structure at a glance. Remove them and you have lost no information, which is why the compact form is a pure formatting choice and never a different identifier.
Two reasons people strip them. The first is storage and column width: a CHAR(36) column holds 36 bytes where the value only needs 16, so databases like MySQL and Postgres offer a binary form (with a helper function such as UUID_TO_BIN()) and a 32-character hex column is the next best thing when a binary type is awkward. The second is environments where punctuation is a nuisance — CSS selectors and HTML element ids, filenames, some log formats, and identifiers embedded in URLs where a dash is easy to misread or to mangle.
The trap is case and context, not the dashes. Hex digits are case-insensitive, so 4c6e... and 4C6E... are the same value — but once you start upper-casing and lower-casing the same ids in different parts of a system you can end up with two strings that fail a naive equality check. And some systems, notably MySQL's UUID_TO_BIN(uuid, 1) with the swap flag, do not merely strip hyphens; they reorder the time fields so the binary sorts chronologically. That is a real transformation, not a cosmetic one.
How to
- Generate as many UUIDs as you need above — they are lowercase and hyphenated by default.
- Need the 32-character version? The UUID formatter converts a whole list at once: pick “32 hex digits, no hyphens” and paste your values.
- Converting in code? Use
replace(/-/g, '')in JavaScript oruuid.hexin Python rather than hand-slicing the string. - Storing in a database? Prefer the native binary type and its helper functions over a text column; 32 hex characters is the compromise, not the goal.
Use cases
- CSS selectors and element ids, where a leading digit or a dash in the middle makes the selector invalid or forces escaping.
- Filenames and log records that must survive shells, globs and tools that treat the dash as an option prefix.
- Compact storage where a binary column is unavailable and every byte of the text form counts.
Compare UUID Without Hyphens with other formats
| Option | When to use |
|---|---|
Canonical (RFC) | 36 characters, lower case, hyphens at 8-4-4-4-12. |
No hyphens | 32 characters, same value, still hex. |
Upper case | Cosmetic. Hex comparison is case-insensitive. |
MySQL UUID_TO_BIN(id, 1) | Not cosmetic — it also swaps the time fields for sortability. |
Base64 / Base64URL | A real re-encoding: fewer characters, but no longer a plain hex UUID. |
Code examples
JavaScript
const id = crypto.randomUUID();
// '4c6e0549-82b1-47b0-9479-211a64583258'
id.replace(/-/g, ''); // '4c6e054982b147b09479211a64583258'
id.replace(/-/g, '').toUpperCase();
// back to canonical form
const hex = '4c6e054982b147b09479211a64583258';
hex.replace(/^(\w{8})(\w{4})(\w{4})(\w{4})(\w{12})$/, '$1-$2-$3-$4-$5');
Python
import uuid
u = uuid.uuid4()
u.hex # '4c6e054982b147b09479211a64583258' (32 chars)
str(u) # '4c6e0549-82b1-47b0-9479-211a64583258'
# both directions parse without loss
uuid.UUID(u.hex) == u # True
uuid.UUID(str(u)) == u # True
SQL
-- MySQL: 16 bytes instead of 36
ALTER TABLE orders ADD COLUMN id_bin BINARY(16);
UPDATE orders SET id_bin = UUID_TO_BIN(id);
-- the second argument reorders the time bytes so the binary sorts by time
SELECT BIN_TO_UUID(id_bin, 1) FROM orders;
-- PostgreSQL keeps hyphens in the uuid type; use BINARY(16) only if you
-- really cannot use uuid, and strip with: replace(id::text, '-', '')
Frequently asked questions
Does removing the hyphens change the UUID?
No. The hyphens are separators for human readability; the 128 bits are in the 32 hex digits. Both forms parse back to the same value, and both are accepted by every mainstream UUID library and database type.
Is a 32-character UUID still a valid UUID?
As a value, yes — the identifier is the same. As a string, the strict RFC form requires the hyphens, so a parser that follows the grammar exactly will reject the unhyphenated form. Most practical parsers and database types are more forgiving, but if you are validating with a regex, decide deliberately which shapes you accept.
What about upper case?
Case is cosmetic: hex digits compare case-insensitively, so 4c6e and 4C6E are the same value. Just be consistent within one system — mixing cases is how you get two strings that look different to an equality check while representing the same identifier.