Base64 Encoder & Decoder

What Is Base64 and When Should You Use It?

Base64 encoding transforms arbitrary binary data into a string composed exclusively of printable ASCII characters. The name refers to the 64-character alphabet used: A-Z, a-z, 0-9, plus (+), and slash (/), with equals (=) used for padding. This encoding is essential whenever binary data must travel through systems designed for text.

The most frequent use case is embedding images or other assets directly inside HTML, CSS, or JSON. Data URIs, for instance, use Base64 to inline small images (data:image/png;base64,...), eliminating an extra HTTP request. Email attachments rely on Base64 through the MIME standard, and many REST APIs require Base64-encoded payloads for binary fields.

Our encoder handles both directions: paste a raw string to get its Base64 form, or paste a Base64 string to recover the original. Everything runs in your browser with the native btoa() and atob() functions, meaning your data never leaves your machine.

Practical Applications for Developers

Embedding assets in code is one of the most common reasons developers reach for Base64. Small icons, fonts, or audio clips can be inlined as data URIs, reducing the number of network requests. For assets under a few kilobytes, this approach often improves page load performance.

API payloads frequently require Base64-encoded content. Cloud storage services like AWS S3 pre-signed requests, image processing APIs, and webhook payloads commonly accept binary data wrapped in Base64. Instead of managing multipart form uploads, you can send everything as a single JSON body.

JWT tokens (JSON Web Tokens) use a URL-safe Base64 variant called Base64url to encode their header and payload segments. Understanding how to decode these segments is invaluable when debugging authentication flows. Paste the token segment into this tool to inspect its JSON contents.

Configuration files in CI/CD systems like GitHub Actions or GitLab CI often store secrets and certificates as Base64-encoded environment variables. You can verify the contents of these values locally before committing them to your pipeline.

Understanding the Size Overhead

Every three bytes of source data become four Base64 characters, which means encoded output is roughly 33% larger than the input. For a 1 KB image, the encoded result is about 1.33 KB. This overhead is negligible for small assets but becomes significant for large files. As a guideline, inline Base64 is most efficient for assets under 10 KB; beyond that, serving the file separately with proper caching is usually faster.

The padding character = appears at the end of Base64 strings when the input length is not a multiple of three. One trailing = means one byte of padding; two means two bytes. Some implementations strip padding because the decoder can infer the original length, but our tool preserves it for maximum compatibility.

Base64 vs Base64url

Standard Base64 uses + and / as its 62nd and 63rd characters, which can cause problems in URLs and filenames. The Base64url variant replaces them with - and _ respectively, and typically omits padding. JWTs, OAuth tokens, and URL query parameters use Base64url. When you encounter a Base64 string with hyphens or underscores instead of plus signs and slashes, you are looking at the URL-safe variant.