Base64 Encoder and Decoder

What Base64 encoding actually is

Base64 is a binary-to-text encoding scheme that turns arbitrary bytes into a string built from 64 printable ASCII characters: A–Z, a–z, 0–9, plus + and /, with = used for padding at the end [4](https://developertoolkit.dev/tools/base64). It exists because many older protocols and text-based formats — email, JSON strings, HTTP headers, URLs — were designed to carry text safely but choke on raw binary bytes like null characters or control codes.

The encoding works by grouping input bytes into chunks of three (24 bits), then re-splitting those 24 bits into four 6-bit groups, each of which maps to one of the 64 output characters. Three raw bytes always become exactly four Base64 characters, which is why Base64 output is roughly 33% larger than the original data.

When the input length isn't a multiple of three, the last group gets padded with = characters to keep the output length a multiple of four. Encoding "Hi" (2 bytes) gives "SGk=", with one padding character; encoding a single byte gives two padding characters, like "QQ==" for the letter "A".

Standard Base64 vs URL-safe Base64

Standard Base64 uses + and / as two of its 64 symbols. Both characters have special meaning inside a URL — + is sometimes interpreted as a space, and / is a path separator — so putting standard Base64 straight into a URL path or query string can silently break it.

URL-safe Base64 (often called Base64URL) swaps + for - and / for _, and conventionally drops the trailing = padding entirely since the padding isn't needed if you know the original data length or can infer it. The same three input bytes that produce SGk= in standard Base64 stay SGk= in Base64URL only when there's no + or / involved; a string like "a+b/c==" would become "a-b_c" in the URL-safe variant [5](https://vibeengines.com/tools/base64-url-tools).

You'll see Base64URL used specifically in JWTs, OAuth tokens, and Firebase or S3 signed URLs — anywhere a Base64-encoded value needs to travel inside a URL without extra percent-encoding on top.

Worked example: encoding and decoding text

Encoding the plain text "Hello, World!" produces "SGVsbG8sIFdvcmxkIQ==". Notice the two trailing = characters — "Hello, World!" is 13 bytes, which isn't a multiple of three, so the encoder pads the final group.

Decoding works in reverse: feed "SGVsbG8sIFdvcmxkIQ==" back in and you get exactly "Hello, World!" back, byte for byte. Base64 is fully reversible and lossless — it's an encoding, not a compression or hashing scheme, so the decoded output is always identical to the original input.

For a URL-safe example: encoding the emoji-containing string "a?b/c" or any text containing bytes that map to + or / in standard Base64 will differ visibly between the two modes — the standard output might contain a / character, while the URL-safe output replaces it with _, making the string safe to drop directly into a query parameter like ?token=eyJhbGciOi....

Base64 and data URIs

A data URI embeds a file's content directly inside a string instead of linking to an external file, using the format data:[mediatype];base64,<encoded data>. For example, a tiny red PNG pixel might appear as data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAB... — the browser decodes that string internally and renders it as if it were a linked image file.

This is common for small icons, inline SVGs, or embedding a font file inside CSS so the browser doesn't need a separate HTTP request. The tradeoff is size: because Base64 inflates data by about a third, a 3KB icon becomes roughly a 4KB string, so this technique is best reserved for small assets rather than large images.

To build one manually, encode the raw file bytes to Base64, then prefix them with data:<mime-type>;base64, — for a JPEG that's data:image/jpeg;base64, followed by the encoded payload.

Base64 and JWTs

A JSON Web Token (JWT) is three Base64URL-encoded segments separated by dots: header.payload.signature. The header and payload segments are each just a JSON object that's been Base64URL-encoded — no encryption, no secret needed to read them [2](https://www.mauriziofonte.it/tools/encoder-decoder-online).

Take a JWT like eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c — decoding the first segment gives {"alg":"HS256","typ":"JWT"}, and decoding the second gives {"sub":"1234567890","name":"John Doe"}. Anyone can decode these two parts; the third segment, the signature, is what actually proves the token wasn't tampered with, and decoding it as text just gives meaningless bytes since it's a cryptographic signature, not encoded JSON.

This is a critical distinction: Base64-decoding a JWT payload to read its claims is completely safe and normal for debugging, but it never verifies the token. Verifying requires checking the signature against the correct secret or public key, which a Base64 tool has no way to do — never treat a decoded-but-unverified JWT as trustworthy input in application logic.

Common mistakes with Base64

Assuming Base64 is encryption is the biggest one. It provides zero confidentiality — anyone can decode it instantly with no key, as shown above with the JWT example. If you need to hide data, use actual encryption; Base64 is purely a format conversion for safe transport.

Mixing up padding is another frequent issue: some systems strip trailing = characters (common in URL-safe contexts), and feeding that stripped string into a strict standard decoder that expects proper padding will throw an "invalid character" or length error. Most modern decoders tolerate missing padding, but not all do.

Forgetting character encoding on the input side causes subtly wrong output for non-ASCII text. "café" needs its UTF-8 byte representation encoded, not a naive per-character mapping — done correctly, "café" becomes "Y2Fmw6k=", not something shorter that assumes one byte per character.

Using the wrong alphabet variant — encoding as standard Base64 when the receiving system expects URL-safe, or vice versa — produces a string that looks almost right but fails to decode wherever a + / - / _ or = character appears.

Practical use cases

Basic HTTP authentication headers use Base64: an Authorization: Basic header value is just "username:password" Base64-encoded, e.g. Authorization: Basic dXNlcjpwYXNz for user:pass. It's not encryption, so Basic auth should only ever be sent over HTTPS.

Embedding binary data in JSON or XML, which are text-only formats, requires Base64 — this is how many APIs let you upload a small image or file as part of a JSON payload rather than a separate multipart request.

Email attachments still rely on Base64 under MIME encoding rules, and inspecting or debugging a JWT, an API key with an embedded encoded payload, or a signed URL parameter routinely means pasting a chunk of it into a Base64 decoder to see the real value underneath.

Privacy and limits

All encoding and decoding here happens locally in your browser's JavaScript runtime — nothing you paste, including tokens, credentials, or file contents, is sent to a server or stored anywhere [4](https://developertoolkit.dev/tools/base64). That matters because Base64 strings often contain sensitive data disguised as harmless-looking text.

There's no hard size limit beyond what your browser can comfortably hold in memory and render in a text box; multi-megabyte strings will work but may feel slow to scroll or select. For encoding actual files rather than pasted text, remember the roughly 33% size increase when estimating how large the resulting string or data URI will be.