UTF-32 UTF-32 (32-bit Unicode Transformation Format) Unicode
A fixed-width encoding using exactly 4 bytes per character — simple to index, but rarely used for storage or transmission due to its size cost.
What it is
UTF-32 encodes every Unicode code point using exactly 4 bytes — no exceptions, no variable width, no surrogate pairs. This makes it the simplest encoding to reason about mathematically: the Nth character in a string is always at byte offset 4 × N, with no scanning required to find character boundaries. That simplicity comes at a real cost, though — UTF-32 is the largest of the major Unicode encodings, using 4 bytes even for plain ASCII text that UTF-8 would represent in 1 byte.
In practice, UTF-32 sees limited real-world use for file storage or network transmission (the size cost usually isn't worth it), but it does show up as an internal representation in some programming language runtimes and libraries specifically because fixed-width indexing simplifies certain string operations.
Byte structure
| Code point range | Bytes used |
|---|---|
| U+0000 – U+10FFFF (all valid Unicode) | Always exactly 4 bytes |
Every single Unicode code point, from basic ASCII letters to rare historic scripts to emoji, takes the same 4 bytes in UTF-32 — there's no distinction based on character complexity or frequency the way UTF-8's variable width provides.
Why your text is garbled (symptom → cause)
| Symptom | Likely cause |
|---|---|
| File appears mostly null bytes when opened in a plain-text viewer expecting UTF-8/ASCII | The file is genuinely UTF-32 — since most common characters have high-order zero bytes in their 4-byte representation, plain-ASCII viewers show long runs of apparent null padding |
| Unexpectedly large file size for what should be simple text | UTF-32's fixed 4-byte-per-character cost — a 100-character plain-English string that would be ~100 bytes in UTF-8 becomes 400 bytes in UTF-32 |
| Byte order mismatch producing scrambled output | Like UTF-16, UTF-32 has BE/LE variants — reading with the wrong endianness produces garbled results |
Compatibility & gotchas
- Rarely chosen for storage or transmission in modern software — the size cost (roughly 4x ASCII, 2x UTF-16 for BMP-heavy text) generally outweighs the indexing simplicity benefit for most real-world use cases, especially given that UTF-8 dominates network/storage contexts.
- Some language runtimes use UTF-32-like fixed-width internal representations for strings specifically to get O(1) character indexing — Python's internal string representation (since Python 3.3's "flexible string representation") dynamically chooses the narrowest fixed width (1, 2, or 4 bytes per character) that fits the actual string content, which is conceptually related but not literally always UTF-32.
- Byte order ambiguity exists just like UTF-16 — UTF-32BE and UTF-32LE are distinct variants, and a byte order mark or explicit declaration is needed to decode correctly without guessing.
- Rarely appears "in the wild" in files developers encounter day-to-day — if you're debugging a garbled file, UTF-32 is a much less likely culprit than UTF-8/Latin-1/Windows-1252 confusion, simply due to how uncommon it is as a storage format.
Fixing it
- Command-line conversion:
iconv -f UTF-32LE -t UTF-8 input.txt -o output.txt(adjustLE/BEto match the source's actual byte order, or use plainUTF-32if a BOM is present to auto-detect it). - Confirming a file is UTF-32: look for the recognizable pattern of 3 null bytes preceding every ASCII character (
0x00 0x00 0x00 'A'for byte order variants, or the reverse for the other endianness) — a strong visual signal distinct from UTF-16's single null byte per ASCII character.
Comparison
| Encoding | Key difference from UTF-32 |
|---|---|
| UTF-8 | Variable 1-4 bytes, ASCII-compatible and much smaller for typical text — the dominant choice for storage/transmission |
| UTF-16 | Variable 2-or-4 bytes via surrogate pairs — smaller than UTF-32 for most real-world text while still not being fully fixed-width |
| UCS-4 | Effectively an older name/synonym for the same fixed 4-byte concept UTF-32 formalizes — the two terms largely overlap in modern usage |
FAQ
Why would anyone use UTF-32 given the size cost?
Mainly for the O(1) fixed-width indexing benefit in specific internal string-processing contexts — knowing that character N is always at byte offset 4×N simplifies certain algorithms. For general storage and transmission, the size cost usually isn't worth it compared to UTF-8.
Is UTF-32 the same as UCS-4?
They're closely related — UCS-4 was an earlier ISO 10646 term for a fixed 4-byte-per-character encoding, and UTF-32 effectively formalized and constrained that same basic idea specifically for representing valid Unicode code points. In practice the terms are often used interchangeably today.
Will I ever need to actually decode a UTF-32 file?
It's uncommon in typical web/application development — UTF-32 shows up more often as an internal representation choice inside specific runtimes/libraries than as a file format you'll encounter from external sources. If you do hit one, standard tools like iconv handle it without issue once you know the byte order.
Fun fact
Despite being the "simplest" Unicode encoding conceptually, UTF-32 is arguably the least-used of the three major UTF encodings in real-world software — its fixed-width simplicity turned out to matter less in practice than UTF-8's compactness and ASCII compatibility, or UTF-16's role as an already-entrenched internal string format in major runtimes established before UTF-32 was finalized.