Encoding

Supported encodings

Two schemes, both defined by RFCs and both reversible by anyone. Base64 makes arbitrary bytes safe for text-only channels; percent-encoding makes text safe for the specific syntax of a URL.

The 33% expansion is inherent, not overhead that better software could avoid: Base64 encodes three bytes as four characters, because 3 × 8 bits divides exactly into 4 × 6 bits. That is the whole design.

Base64

Base64 converts binary data into text using a set of 64 printable characters. It is the usual way to carry binary files — images, documents, audio — through channels that only accept text, such as email bodies and HTTP headers.

Embedding and transport

Base64 is commonly used for embedding images in HTML, sending binary files through email, or encoding data in web technologies like JSON or XML.

The string "hello" in Base64 encoding would become aGVsbG8=

URI-Encoding

URI encoding, also known as percent encoding, rewrites characters that a URL cannot carry literally into a form that survives transmission. Spaces, punctuation and non-ASCII symbols each become an escape sequence, so the URL still parses the way its author intended.

Query parameters and form data

URL encoding is commonly used to encode query parameters in URLs (e.g., form submissions, search queries) and to ensure safe transmission of data via HTTP requests.

The phrase "A + B = C" in URL encoding would be: A%20%2B%20B%20%3D%20C

How Base64 works

Input bytes are taken three at a time — 24 bits — and re-split into four groups of six. Each 6-bit group indexes the 64-character alphabet, which is where the name comes from. Six bits is exactly enough to address 64 symbols, and 64 symbols are enough to stay inside the printable ASCII that every text channel passes through unharmed.

When the input length is not a multiple of three, the final group is short. The remaining bits are padded with zeros and the output is padded with = to keep the length a multiple of four. That is all the equals signs mean, and it is why they only ever appear at the end.

Encoding is not encryption

This is the single most important thing to understand about Base64, and it is a genuinely common and costly misunderstanding.

Encoding changes how data is represented so it can travel safely through a system that only handles text. It is a public, reversible transformation with no key involved — anyone can decode it instantly, including with this tool. Encryption is different: it changes data so that it cannot be read at all without the right secret.

So Base64 provides no confidentiality whatsoever. A password, API token, or personal record that is merely Base64-encoded is, for practical purposes, stored in plain text. It looks scrambled to a human, which is exactly what makes the mistake so easy to make. If you need secrecy, use the encryption tool instead.

When to use which

Base64

Use it when binary data has to pass through something that expects text. Email attachments, images embedded directly in HTML or CSS as data URIs, binary fields inside JSON or XML, and certificates in PEM format all rely on it. The cost is size: output is about 33% larger than the input, because every three bytes become four characters.

URL encoding

Use it for anything placed into a URL. Spaces, ampersands, question marks, slashes, and non-ASCII characters all carry structural meaning in a URL, so they must be percent-escaped to survive as data rather than being parsed as syntax.

A practical example: to search for "cats & dogs" the query has to become cats%20%26%20dogs — leave the ampersand raw and the server treats "dogs" as a separate parameter, which is the classic cause of a search that silently drops half its terms.

Common uses

• Reading a JWT payload— the segments of a token are Base64url-encoded, so decoding one shows the claims inside.
• Basic authentication headers— these carry user:password as Base64, which is precisely why the scheme requires HTTPS to be safe at all.
• Data URIs— embed a small image or font directly in a stylesheet and avoid an extra network request.
• Debugging query strings— decode a URL to see what a form or redirect actually submitted.
• Inspecting configuration— Base64 blobs turn up throughout deployment files and cloud metadata.
• Email headers— non-ASCII subject lines are encoded, which is why a subject sometimes appears as gibberish in a raw message.

Things that trip people up

• The trailing equals signs.Base64 works in three-byte groups and pads with = when the input does not divide evenly. Many decoders reject input whose padding has been stripped; this one restores it for you, but do not assume the system on the other end is as forgiving.
• Accented and non-Latin characters.Base64 encodes bytes, not characters, so the text has to become bytes first. This tool uses UTF-8 (RFC 3629), which is what browsers and APIs expect. Implementations built on btoa() alone reject anything above U+00FF outright, which is why emoji and Cyrillic text fail on some other sites.
• Base64 and Base64url differ.The URL-safe variant swaps + and / for - and _ so the value survives inside a URL. JWTs use the URL-safe form.
• Encoding twice is a real bug.A URL-encoded string encoded a second time turns %20 into %2520 and the result arrives with visible escape codes in it.
• Plus is not a space everywhere.In query strings + historically means a space; in a path segment it means a literal plus. The rule comes from the form-encoding serialisation rather than from RFC 3986 itself, which is why the two disagree and why the confusion is genuine rather than careless.
• Line breaks in pasted Base64.Some systems wrap long output at a fixed width — RFC 2045 requires 76 characters for MIME, which is why PEM certificates and email attachments arrive in ragged columns. RFC 4648 forbids those newlines unless the referring specification permits them, so a strict decoder rejects wrapped input that a lenient one accepts. Removing the line breaks is usually all that is needed.