Convert any file into text using base encoding schemes — practical, URL-friendly, compact, and educational
The need to represent binary data in text form emerged with early computer networks. ASCII, standardized in 1963, used 7 bits per character, but many transmission channels required 8-bit clean communication. The challenge was converting arbitrary binary data into printable characters without loss. [Wikipedia, ASCII]
In the early 1980s, uuencoding (Unix-to-Unix encoding) became popular for transmitting binary files over Usenet and email systems. It converted 3 bytes to 4 printable characters using a 64-character subset, achieving 75% efficiency. This laid the conceptual foundation for Base64. [Wikipedia, Uuencoding]
In 1992, the Multipurpose Internet Mail Extensions (MIME) standard formalized Base64 as an encoding method for email attachments. RFC 1521 specified the character set A-Z, a-z, 0-9, +, / with = padding, the exact scheme used in modern web technologies. This standardization enabled email systems worldwide to exchange binary files reliably. [RFC 1521, MIME]
As technology evolved, specialized encodings emerged. Base58 was introduced by Satoshi Nakamoto for Bitcoin addresses in 2009, removing visually ambiguous characters (0, O, I, l) to reduce transcription errors. Base62 became popular for URL shorteners like bit.ly due to its alphanumeric-only character set. Base91 was developed by Joachim Henke for high-efficiency encoding, achieving around 23% overhead versus Base64's 33%. Base2048 was developed by qntm to maximize data density in Unicode-aware character-limited platforms like Twitter, encoding 11 bits per character using 2,048 safe Unicode code points. [Wikipedia, Base58] [Base2048 by qntm]
All base encoding works on the same principle: treat the entire binary input as one large number, then convert it to a different base representation. For Base64, each group of 3 bytes (24 bits) is divided into 4 groups of 6 bits, each mapping to a printable character. For Base16 (hexadecimal), each byte maps to two characters (4 bits per character). [Wikipedia, Base64]
Given binary data as a sequence of N bytes, you treat it as a base-256 number (each byte is 0-255). To encode to base M, you repeatedly divide by M and collect remainders as indices into a character set. For example, encoding "Man" to Base64: M=ASCII 77, a=97, n=110 combines to 0x4D616E = 4,874,094 in decimal, then convert to base-64.
Most practical encodings use a fixed input block size for efficiency. Base64 processes 3 bytes at a time, Base32 processes 5 bytes (40 bits to 8 groups of 5 bits), and Base16 processes 1 byte at a time. This block processing enables streaming and vectorized implementations. [RFC 4648, Base Encoding]
Different encodings achieve different space efficiencies. Base2 (binary) expands data 800% (1 byte becomes 8 characters). Base16 expands 100% (1 byte becomes 2 hex characters). Base64 expands 33% (3 bytes become 4 characters). Base85 expands 25% (4 bytes become 5 characters). Base91 expands approximately 23% (13 bytes become 14 characters). Base2048 approaches 91% efficiency (11 bits per character). The trade-off is between human readability and compactness.
Most block-based encodings use padding to handle input lengths not divisible by the block size. Base64 uses '=' padding characters to indicate how many of the output characters are part of the real data. Padding ensures decoders know exactly how many original bytes were present. Some schemes like Base62 and Base58 avoid padding entirely by using variable-length output.
Character Set: A-Z, a-z, 0-9, +, / | Padding: = | Efficiency: 75% | Output Size: 4 chars per 3 bytes
RFC 4648 standard. Used everywhere: email attachments (MIME), data URLs (data:image/png;base64), JSON web tokens (JWT), HTML/CSS embedded assets, and cryptographic key representations. Processes input in 3-byte blocks. Approximately 75% efficiency means a 1 MB file becomes about 1.33 MB of Base64 text. [Wikipedia, Base64]
Character Set: 33-117 (ASCII printable) | Padding: u | Efficiency: 80% | Output Size: 5 chars per 4 bytes
Developed by Paul Rutter for Adobe's PostScript and PDF formats. Encodes 4 bytes (32 bits) into 5 ASCII characters using base-85 conversion. More efficient than Base64, reducing output size by about 25%. Two variants exist: Adobe Ascii85 (used in PDF) and RFC 1924 (an improved version). Base85 output is safe for inclusion in PostScript strings since it avoids parentheses and backslashes. [Wikipedia, Ascii85]
Character Set: 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz | Padding: None | Efficiency: Approx 73% | Special Feature: No visually similar characters
Created by Satoshi Nakamoto and first included in the original Bitcoin source code released in 2009. Removes easily confused characters: 0 (zero), O (capital o), I (capital i), l (lowercase L). Also excludes + and / from Base64 to make addresses double-clickable and safe to copy. Used in Bitcoin addresses, IPFS (InterPlanetary File System) IDs, and various cryptocurrency wallets. The removal of ambiguous characters reduces human transcription errors significantly. [Wikipedia, Base58]
Character Set: 0-9, A-Z, a-z | Padding: None | Efficiency: Approx 74% | Use Case: Short URL generation
Uses all alphanumeric characters (10 digits + 26 uppercase + 26 lowercase = 62 characters). No padding required as it uses variable-length output. Popular for URL shorteners (TinyURL, bit.ly), unique ID generators, and database key generation. Provides a good balance between compactness and human readability. A 6-character Base62 string represents over 56 billion possible values (62^6 = 56,800,235,584), sufficient for most ID generation needs. [Wikipedia, Base62]
Character Set: 91 printable ASCII characters (excluding space, apostrophe, hyphen, and backslash) | Padding: None | Efficiency: ~77-86% | Output Size: ~14 chars per 13 bytes on average
Developed by Joachim Henke and published at base91.sourceforge.net. Uses 91 printable ASCII characters, achieving significantly better efficiency than Base64 — typically around 23% overhead versus Base64's 33%. Divides the binary stream into 13-bit packets, each encoded as 2 characters (since 91² = 8,281 which exceeds 2¹³ = 8,192). Useful for email, terminal lines, and embedded systems where every byte counts. [Base91 by Joachim Henke]
Character Set: 2,048 safe Unicode code points | Padding: Minimal | Efficiency: ~137.5% vs Base64's 75% | Special Feature: 11 bits per character
Developed by qntm (Sam Hughes) to maximize data density on platforms like Twitter that count Unicode code points rather than bytes. Base2048 is an 11-bit encoding — each character encodes 11 bits of data, compared to Base64's 6 bits per character. A single 280-character tweet can carry 3,080 bits (385 bytes) of Base2048 data. Uses only "safe" Unicode code points: no unassigned characters, no control characters, no whitespace, and no combining diacritics. [Base2048 by qntm on GitHub]
Base2 (Binary): 0/1, 12.5% efficiency - teaches fundamental concepts
Base8 (Octal): 0-7, 33% efficiency - Unix file permissions
Base10 (Decimal): 0-9, 41% efficiency - human-readable numbers
Base16 (Hex): 0-9A-F, 50% efficiency - debugging and color codes
Base32: A-Z2-7, 62.5% efficiency - case-insensitive applications like Steam
Base36: 0-9a-z, 64% efficiency - compact yet readable IDs
These encodings are included primarily for educational purposes to demonstrate how different base representations affect data size and character readability. [Wikipedia, Base32]