Universal encoding converter. Paste hex, binary, Base64, URL-encoded, HTML entities, Unicode escapes, or plain text. Auto-detect format and convert to all others instantly. Supports UTF-8, UTF-16, UTF-32, Base64, URL encoding, HTML entities, JavaScript/Python/CSS escapes, Morse code, ROT13, JWT decode, and more. 100% local — nothing leaves your browser.
Underneath everything, computers only understand binary (0s and 1s). However, humans and many internet protocols (like HTTP and JSON) are specifically designed to handle standard text characters (A-Z, 0-9).
When a developer needs to send a binary file (like an Image or a compiled PDF) inside a JSON text payload, they must encode the binary data into safe text characters so the transport layer doesn't break.
Hexadecimal uses 16 characters (0-9 and A-F) to represent binary data. Every byte (8 bits) can be perfectly represented by exactly 2 Hex characters (e.g., 11111111 becomes FF).
Hex is incredibly easy for programmers to read and debug, but it is highly inefficient for data transfer over a network because it doubles the size of the payload (1 raw byte requires 2 text bytes to represent it).
Base64 was invented to fix the size problem of Hex. Instead of 16 characters, it uses 64 characters (A-Z, a-z, 0-9, +, /). Because it has a much larger dictionary, it can pack more binary data into fewer text characters.
Base64 groups 24 bits (3 bytes) and translates them into just 4 text characters. This means Base64 only increases the payload size by about 33% (compared to Hex's 100%), making it the industry standard for embedding images directly into HTML/CSS files or sending files through text-based APIs.
Why do developers use Base64 to encode images in JSON payloads instead of Hexadecimal?
