01 / Why binary data needs text encodings
Early email and text links could not reliably carry arbitrary bytes. MIME standardized Base64 transfer encoding in the 1990s; RFC 4648 brought Base16, Base32, Base64 and their variants together in 2006, specifying alphabets, padding and canonical forms. Base64 turns three bytes into four six-bit symbols, usually adding about a third to the size. It is not compression.
Encoding needs no secret. Anyone can reverse it; it is not encryption, hashing, signing or redaction. Decide which bytes the text represents before choosing an encoding. Chinese characters, emoji, line endings and Unicode normalization all matter. This page neither trims nor normalizes input. If binary data is not valid UTF-8, inspect it as Hex rather than forcing a text interpretation.
A decoder must also check unused padding bits. Producing the same bytes does not make every spelling canonical. Mixed alphabets, invalid padding bits and implicit whitespace are rejected here. Base64 and Base64url accept canonical padded or unpadded forms.
02 / URL-safe is not protocol-safe
Base64 uses +, / and =. Base64url replaces + and / with - and _, making it easier to use in URLs, filenames and protocol fields. Whether = may be omitted is a protocol decision; JOSE/JWS uses unpadded Base64url. This is different from encodeURIComponent's percent encoding. Form encoding can also interpret + as a space.
A typical JWT has three Base64url parts, but decoding its header or payload verifies neither its signature nor its issuer, audience or expiry. JWE is a separate encrypted format. JWK uses Base64url too, with different rules for RSA unsigned integers and fixed-width EC/OKP fields. Leading zeros and widths cannot be treated interchangeably.
PEM adds BEGIN/END labels and line-break rules around Base64 text; DER is a binary ASN.1 encoding. This tool converts raw bytes. It does not identify a bare Base64 value as a certificate, PKCS#8 key or JWK.
03 / Base58 and checksummed encodings
Bitcoin's Base58 alphabet leaves out easily confused characters such as 0, O, I and l. This page uses that case-sensitive alphabet and preserves leading zero bytes as leading 1s. Flickr and XRP use different alphabets. Plain Base58 includes neither a checksum nor an automatic network or type identifier.
Base58Check appends the first four bytes of a double SHA-256 hash before Base58 encoding. Protocols often add version or prefix bytes first; you must supply those bytes yourself. Decoding checks and removes the checksum while retaining the full prefix and payload. A checksum detects errors, but an attacker can recompute it. It provides neither authentication nor confidentiality.
Bech32 (BIP 173, 2017) combines an HRP, data and six checksum characters. Bech32m (BIP 350, 2021) changes the checksum constant; the two are not interchangeable, and mixed case is forbidden. This page uses a generic bytes-to-five-bit-words container with a 90-character limit. It is not a Bitcoin address parser. SegWit also needs witness-version, program-length, network-HRP and checksum-type checks.
Define the field before choosing its representation
Specify each field's raw type, byte order, encoding, case, padding and maximum length. A key ID is an identifier, not a place for recoverable secrets. A random token gets its entropy from random bytes, not Base64 or Base58. Normalize only at a boundary defined by the protocol. Signature verification must use the protocol's exact bytes, not JSON that has been casually reordered or re-encoded.
Base58 input is limited to 8 KiB to bound big-integer conversion costs. Other formats allow up to 1 MiB of bytes and 2 MiB of encoded text; Bech32 variants are limited to 90 characters. Conversion runs in a local Worker without network requests or input storage. A valid checksum is not evidence of a trusted source.