Skip to content
BetterPass logo

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.

Flow diagram: input text converts to 8-bit binary bytes, splits into 6-bit groups, then maps to Base64 output characters

How Base64 Encoding Works

Hello

Input Text

01001000 01100101

8-bit Bytes

010010 000110 0101

6-bit Groups

SGVsbG8=

Base64 Output

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

Standard: Base64
In URLs: Base64URL

Human-Readable / Crypto

Addresses, keys, sharing verbally, QR codes

Bitcoin/IPFS: Base58
Case-insensitive: Base32

Binary Inspection / Low-Level

Debugging, forensics, embedded systems, protocols

Byte-for-byte: Hex
Space-efficient: ASCII85

Web Forms / Query Strings

Form submits, redirects, query params

Required: URL Encoding
Standard: RFC 3986

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

Base64Standard for APIs & data URIs60 chars · +136%
HexHash digests & debugging88 chars · +200%
Base58Bitcoin & IPFS addresses60 chars · +136%
Base32TOTP secrets & license keys72 chars · +164%
ASCII85PDF & PostScript streams55 chars · +125%
URLQuery strings & form data60 chars · +136%

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: %20 only
  • 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

  1. Copy JWT (3 parts separated by .)
  2. Split on . → header.payload.signature → 3 segments
  3. Decode each with Base64URL Decode
  4. Inspect header (alg, typ) + payload (claims)
  5. Verify signature separately (not in browser)

Convert Certificate Formats

  1. PEM (Base64 + headers) → strip headers
  2. Decode with Base64 Decode → DER binary
  3. Re-encode with Base64 Encode for transport
  4. Use Hex for fingerprint comparison

Build OAuth Redirect URL

  1. Encode each param value with URL Encode
  2. Join with & → query string
  3. Append to authorization endpoint
  4. Critical: redirect_uri MUST be encoded

Verify Download Integrity

  1. Get SHA-256 hash from vendor
  2. Open SHA-256 Hash tool
  3. Drop downloaded file → compute hex
  4. Compare with vendor hash (case-insensitive)

Encode Binary Key for JSON

  1. Generate key (32 bytes for AES-256)
  2. Encode with Base64 Encode
  3. Store in JSON config / env var
  4. Decode at runtime before crypto use

Create Human-Readable Invite Code

  1. Generate 64-bit random ID
  2. Encode with Base32 Encode (no padding)
  3. Result: ~13 chars, case-insensitive
  4. 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 → Hashing

Password storage & salting with Bcrypt, Argon2, scrypt

Hashing → Encoding

Hex/base64 representation of hash digests

Encoding → Tokens

Base64URL in JWT

Tokens → Serialization

Protobuf for efficient token payload serialization