Introduction
Building a URL shortener, encoding binary data for transmission, or debugging a JWT? Encoding and decoding tools convert data between formats for storage, transmission, and display. Unlike encryption, encodings are reversible and public—anyone with the algorithm can decode the data. These tools handle Base64, Base32, Base62, URL encoding, hexadecimal, and more. All processing happens in your browser; your data never leaves your device.
What this category includes
- Base64 and Base32 encoders/decoders following RFC 4648 standards
- Base62 for URL-safe integer-to-string conversion without special characters
- URL encoding/decoding for percent-encoding per RFC 3986
- Hexadecimal (base-16) and binary (base-2) converters for raw data inspection
- UTF-8 encoding tools for handling Unicode and international text
How these tools work
Binary-to-text encodings represent binary data as ASCII characters. Base64, defined in RFC 4648, uses 64 characters (A-Z, a-z, 0-9, +, /) and pads with '=' to make the output length a multiple of 4. Every 3 bytes of input become 4 characters of output, achieving 75% efficiency. Base32 uses 32 characters (A-Z, 2-7) for case-insensitive applications, achieving 62.5% efficiency.
Base62 uses only alphanumeric characters (0-9, A-Z, a-z), avoiding the +, /, and = characters that require URL-encoding. This makes it ideal for URL shorteners and database ID obfuscation. The encoding converts integers to base-62 strings using a character mapping array.
URL encoding (percent-encoding) replaces unsafe ASCII characters with %XX hex representations per RFC 3986. Spaces become %20 or +, and reserved characters like ? and & are encoded to prevent them from being interpreted as URL delimiters.
How the underlying systems work
The need for binary-to-text encoding arose from systems that only supported 7-bit ASCII. Email protocols (SMTP), early filesystems, and legacy databases couldn't store raw binary data. Base64 was standardized in 1987 (RFC 989) and revised in RFC 4648 in 2006 to consolidate multiple variants.
Base64's efficiency comes from using 6 bits per character (2^6 = 64). Three 8-bit bytes (24 bits) map to four 6-bit characters. The padding character '=' indicates how many bytes of padding were added: none, one, or two bytes.
Base32 uses 5 bits per character (2^5 = 32). Five 8-bit bytes (40 bits) map to eight 5-bit characters. The alphabet avoids visually similar characters (0 vs O, 1 vs I vs L) to reduce transcription errors.
URL encoding addresses the fact that URLs have a restricted character set. RFC 3986 defines reserved characters that have special meaning (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) and unsafe characters that should be encoded (space, <, >, ", {, }, |, \, ^, ~, [, ], `). Percent-encoding represents these as %XX where XX is the hexadecimal byte value.
How to use these tools
- Choose the encoding type based on your use case (Base64 for email, Base62 for URLs, hex for debugging)
- Paste your input data—text, binary, or already-encoded strings
- View the output instantly as you type; the tool auto-detects input format when possible
- Copy the result with one click or download it as a file
- For decoding, paste the encoded string and the tool reverses the process
Real-world examples
URL Shortener Implementation
A Node.js developer builds a URL shortener. Database IDs are integers (1024, 2048, 4096). Using the Base62 tool, ID 1024 converts to 'g8'—a short, URL-safe string. The tool handles large integers using BigInt, converting IDs up to 2^53-1. The reverse conversion decodes 'g8' back to 1024 for database lookup.
JWT Debugging
A developer debugging a JWT (JSON Web Token) sees three dot-separated segments. The Base64 tool decodes the header and payload to reveal the claims (iss, exp, sub). The signature remains encoded as it's cryptographic. This helps verify token contents without a library.
Email Attachment Encoding
An email system needs to send binary files. The tool converts a PDF to Base64, producing a string like 'JVBERi0xLjQK...'. The email client decodes it back to binary on receipt. The tool handles large files efficiently and validates Base64 checksums.
Comparison of methods
| Method | Complexity | Typical use |
|---|---|---|
| Base64 | O(n) | Email, JWTs, data URIs |
| Base32 | O(n) | Case-insensitive IDs, TOTP |
| Base62 | O(n) | URL shorteners, obfuscation |
| Hex | O(n) | Debugging, binary inspection |
| URL Encoding | O(n) | HTTP parameters, query strings |
Limitations
Encodings are not encryption. Base64, Base32, and Base62 are publicly reversible algorithms—anyone can decode the data. They provide no confidentiality. Use them for data representation, not secrecy. For sensitive data, encrypt first (with AES), then encode the ciphertext. Also, encoding increases data size: Base64 adds ~33%, Base32 adds ~60%. For bandwidth-sensitive applications, consider binary transmission instead.
Frequently asked questions
Related categories
Conclusion
Encoding and decoding tools solve data representation problems across web development, email systems, and data storage. Use Base64 for email and JWTs, Base62 for URLs, and hex for debugging. Remember that encoding is not encryption—for secrecy, pair these with proper cryptographic tools from the Security & Hashing category.