Online Encoding Tools — Base64, Hex, URL, Base58 & Base32 Converter
Convert text and binary data across encoding formats. 100% client-side, your tool data never leaves your browser. Choose the right format for your use case with the guide below.
Each tool accepts files too — drop a file to encode or decode its contents directly, no pasting needed.
What Is Data Encoding? Base64, Hex, and URL Encoding Explained
Ever seen a jumble of letters and numbers like “dGhpcyBpcyB0ZXh0” and wondered what it means? That’s data encoding — a way to convert information from one format into another using a publicly known scheme that is fully reversible. Unlike encryption, encoding requires no secret key — anyone can decode the data if they know the algorithm. Encoding is used primarily for compatibility: ensuring binary data can be transmitted over text-only protocols (like email or JSON), represented in URLs, or displayed in human-readable forms. Common encoding formats include Base64, Hex, URL encoding, Base32, Base58, and ASCII85, each optimized for different transport and readability requirements.
Base64 encoding is the most widely used encoding on the web — it powers email attachments (MIME), JSON binary data, data URIs, and Basic Auth credentials. Hex (Base16) provides a direct byte-to-character mapping that is indispensable for inspecting hash digests, debugging network protocols, and working with color codes. URL encoding (percent-encoding) ensures that reserved characters in URIs can be safely transmitted in query strings and path segments. Base58 removes visually confusing characters and is the standard for Bitcoin addresses and IPFS content identifiers. Base32 offers case-insensitive encoding ideal for TOTP secrets and license keys. ASCII85 (Base85) is more space-efficient than Base64 and is used in PDF and PostScript streams.
Encoding and Encryption are distinct from each other. Base64-encoded data is trivially decoded by anyone — there is no secrecy. Never use encoding to protect sensitive information like passwords, API keys, or personal data. For confidentiality, use proper encryption or cryptographic hashing (for passwords). Encoding is purely about data format compatibility and transport safety, not security. All BetterPass encoding tools run entirely in your browser — your data stays on your device.
How Base64 Encoding Works
Hello
Input Text
01001000 01100101
8-bit Bytes
010010 000110 0101
6-bit Groups
SGVsbG8=
Base64 Output
Base64 Encode/Decode
Encode text to Base64 for email attachments (MIME), data URIs, and JSON binary payloads. Supports standard Base64 and URL-safe Base64URL with instant browser-side conversion.
Hex Encode/Decode
Convert text to hexadecimal for hash digest inspection, color codes, UUIDs, and protocol debugging. Direct byte-to-character mapping makes hex ideal for checksum verification.
URL Encode/Decode
Percent-encode reserved characters in URLs for safe query strings, path segments, and form submissions. RFC 3986 compliant with %20 and + space encoding options.
ASCII85 / Base85
Encode binary data to ASCII85 (Adobe Base85) for PDF streams, PostScript, and git binary patches. More space-efficient than Base64 with only 25% overhead.
Base32 Encode/Decode
Encode text to Base32 for TOTP secrets, DNSSEC keys, and case-insensitive transmission. Uses A-Z,2-7 alphabet — no visually confusing characters like 0, O, I, l.
Base58 Encode/Decode
Encode data to Base58 for Bitcoin addresses, IPFS CIDs, and Solana keys. Removes confusing characters (0,O,I,l) for safe verbal sharing and double-click selection.
Encoding Detective
Not sure what you have? Paste any unknown string and get ranked candidates — Hex, Base64, Base32, Base58, ASCII85, URL — with evidence and a decoded preview.
Not sure what you have?
If you found an opaque string in a config file, database row, or log line and don't know which format it uses, paste it into the Encoding Detective. It checks each format's alphabet, length rules, and padding, ranks the candidates with a confidence score, shows what each one decodes to, and links you straight to the right converter.
Choosing the Right Encoding Format
Encoding isn't one-size-fits-all. The right format depends on what you're trying to achieve:
1. Web / JSON / Email Transport
Base64 — Best for email attachments (MIME), JSON binary data (images, files), Basic Auth credentials, and data URIs. Groups 3 bytes into 4 ASCII characters. Standard alphabet uses A-Z, a-z, 0-9, +, / with = padding. 33% overhead.
Base64URL — Use when Base64 output goes in URLs, query parameters, or JWT tokens. Replaces + with - and / with _, omits = padding. Required for JWT header.payload.signature format.
2. Human-Readable / Crypto Addresses
Base58 — Best for Bitcoin addresses, IPFS CIDs, and Solana keys. Removes visually confusing characters (0, O, I, l) from Base64. Includes checksum in Bitcoin addresses. No confusing punctuation — double-click selects the whole string.
Base32 — Best when case-insensitivity matters: TOTP secrets (Google Authenticator), DNSSEC key identifiers, license keys. Uses A-Z, 2-7 alphabet. Case-insensitive for safe spoken/typed communication.
3. Binary Inspection & Low-Level Debugging
Hex (Base16) — Best for hash digests (SHA-256: 64 hex chars), hex dumps, memory inspection, and color codes. Direct byte-to-char mapping — trivial to parse and debug. 100% overhead (2× size).
ASCII85 (Base85) — Best when space efficiency matters. Encodes 4 bytes into 5 ASCII chars (25% overhead vs Base64's 33%). Used in PostScript, PDF, and git binary patches. Z85 variant avoids quoting issues.
4. Web Forms & URL Parameters
URL Encoding (Percent-Encoding) — Required for query strings, form submissions, and URL path segments. Replaces reserved characters (! * ' ( ) ; : @ & = + $ , / ? % # [ ]) with %XX hex codes. Use %20 for paths, + for query strings.
Quick Format Selection
Web / JSON / Email
Standard transport, APIs, JWT payloads, Basic Auth
Human-Readable / Crypto
Addresses, keys, sharing verbally, QR codes
Binary Inspection / Low-Level
Debugging, forensics, embedded systems, protocols
Web Forms / Query Strings
Form submits, redirects, query params
Base64 vs Base58 vs Base32: Choosing the Right Encoding
Base64
Binary-to-text for APIs, email attachments, data URIs, and JWTs. ~33% size overhead. Use when compatibility with web standards is the priority — every platform has a Base64 decoder built in.
Base58
Human-friendly for cryptocurrency addresses (Bitcoin) and invoices. Removes lookalike characters (0, O, I, l). Slightly less efficient than Base64 but copy-paste safe in any font.
Base32
Case-insensitive for TOTP secrets, DNSSEC, and OpenPGP fingerprints. ~60% overhead over raw binary but eliminates case-entry errors — ideal when users must manually transcribe the output.
Encoding Size Comparison
Relative encoded length vs the raw byte size. All encoding happens locally in your browser.
Format Deep Dive
Base64 & Base64URL
How It Works
Groups 3 bytes (24 bits) → 4 × 6-bit values → maps to A-Z, a-z, 0-9, +, /. Padding with = to 4-char multiples. 33% overhead.
Variants
- Standard (RFC 4648 §4): +, /, = padding
- URL-safe (RFC 4648 §5): -, _, no padding (Base64URL)
- MIME (RFC 2045): Line length ≤ 76 chars, CRLF
Use Cases
- Email attachments (MIME)
- JSON binary data (images, files)
- JWT tokens (Base64URL, no padding)
- Basic Auth credentials
- Data URIs (data:image/png;base64,...)
- CSS embedded fonts/images
Common Pitfalls
- Forgetting Base64URL for JWT → signature validation fails
- Double-encoding (encoding already-encoded data)
- Assuming padded vs unpadded compatibility
Hex (Base16)
Properties
- 2 hex chars per byte (0-9, A-F)
- 100% overhead (2× size)
- Case-insensitive (typically lowercase)
- Direct byte-to-char mapping — trivial to parse/debug
Use Cases
- Hash digests (SHA-256: 64 hex chars)
- Hex dumps, memory inspection, forensics
- Color codes (#RRGGBB)
- UUID/GUID representation
- Raw protocol analysis (TCP, TLS, etc.)
URL Encoding (Percent-Encoding)
RFC 3986 Reserved Characters
Must be encoded: ! * ' ( ) ; : @ & = + $ , / ? % # [ ]
Space Handling
- Query string:
+or%20 - Path segment:
%20only - Form data (application/x-www-form-urlencoded):
+
When to Encode
- Building query strings manually
- User input in URLs (search, redirects)
- OAuth redirect_uri parameter
- Form POST body (application/x-www-form-urlencoded)
Don't Double-Encode
Encoding an already-encoded string turns %20 into %2520. Decode first if unsure.
Base58 (Bitcoin, IPFS, Solana)
Alphabet
Base64 minus visually similar chars: 0 (zero), O (capital o), I (capital i), l (lowercase L). Also removes + and /.
Variants
- Bitcoin: Leading 1s encode leading zero bytes (address prefix)
- IPFS (CIDv0): Multibase prefix 'z' + Base58BTC
- Solana: Base58 with different leading char handling
- Flickr: Short photo IDs
Why Base58?
- No confusing chars when reading aloud or typing
- Double-click selects whole string (no punctuation)
- Shorter than Base64 for same data (58 vs 64 alphabet)
- Checksum built into Bitcoin addresses (last 4 bytes)
Base32 & Base32Hex (RFC 4648)
Two Alphabets
- Base32 (RFC 4648 §6): A-Z, 2-7 — case-insensitive, no 0,1,8,9
- Base32Hex (RFC 4648 §7): 0-9, A-V — preserves sort order
Properties
- 5 bits per char → 8 chars per 5 bytes (20% overhead vs Base64's 33%)
- Padding with = to 8-char multiples
- Case-insensitive — safe for DNS, file systems, spoken comms
Use Cases
- TOTP secrets (Google Authenticator, RFC 6238)
- DNSSEC key identifiers
- File systems with case-insensitive names
- Human-readable codes (license keys, invite codes)
- Base32Hex: sorted keys in databases
ASCII85 / Base85 (Adobe, Z85, b85encode)
Efficiency
4 bytes → 5 ASCII chars (25% overhead vs Base64's 33%). Uses 85 printable chars (! through u).
Variants
- Adobe (PostScript/PDF):<~ ... ~{gt; delimiters, z for 4 zero bytes
- Z85 (ZeroMQ/RFC 9284): Different alphabet, no delimiters, for message framing
- Python b85encode: Adobe-compatible, no delimiters
Use Cases
- PDF embedded streams (images, fonts)
- Git binary patches (delta compression)
- ZeroMQ message framing
- PostScript Level 2+ binary data
Common Workflows
Debug JWT Token
- Copy JWT (3 parts separated by .)
- Split on . → header.payload.signature → 3 segments
- Decode each with Base64URL Decode
- Inspect header (alg, typ) + payload (claims)
- Verify signature separately (not in browser)
Convert Certificate Formats
- PEM (Base64 + headers) → strip headers
- Decode with Base64 Decode → DER binary
- Re-encode with Base64 Encode for transport
- Use Hex for fingerprint comparison
Build OAuth Redirect URL
- Encode each param value with URL Encode
- Join with & → query string
- Append to authorization endpoint
- Critical: redirect_uri MUST be encoded
Verify Download Integrity
- Get SHA-256 hash from vendor
- Open SHA-256 Hash tool
- Drop downloaded file → compute hex
- Compare with vendor hash (case-insensitive)
Encode Binary Key for JSON
- Generate key (32 bytes for AES-256)
- Encode with Base64 Encode
- Store in JSON config / env var
- Decode at runtime before crypto use
Create Human-Readable Invite Code
- Generate 64-bit random ID
- Encode with Base32 Encode (no padding)
- Result: ~13 chars, case-insensitive
- User types easily, no confusion
Encoding ≠ Encryption
Encoding (Public, Reversible)
- No secret key required
- Anyone can decode
- Purpose: transport, compatibility
- Examples: Base64, Hex, URL, ASCII85
Encryption (Secret, Reversible with Key)
- Requires secret key
- Only key holder can decrypt
- Purpose: confidentiality
- Examples: AES-GCM, ChaCha20-Poly1305, RSA-OAEP
Never use encoding to protect secrets. Base64-encoded passwords, API keys, or tokens are trivially decoded. Use encryption (or hashing for passwords) instead.
Frequently Asked Questions
Encoding transforms data into a different format using a public algorithm. It is fully reversible without a secret — anyone can decode the data if they know the method.
Encryption transforms data using a secret key. Only someone with the key can reverse it.
Use encoding for compatibility and transport. Use encryption for confidentiality. They are not the same thing.
Related Tools — Explore the Full Toolchain
Encoding data? Learn about Base64URL in JWT tokens →
Password storage & salting with Bcrypt, Argon2, scrypt
Hex/base64 representation of hash digests
Base64URL in JWT
Protobuf for efficient token payload serialization