Base64 Encoder & Decoder

What Base64 is and when to use it

Base64 is a way of representing arbitrary binary data using 64 printable ASCII characters: A–Z, a–z, 0–9, plus and slash, with = as padding. Every 3 bytes of input become 4 characters of output, so encoded data is about 33% larger than the original. It exists because many channels were designed for text only: email attachments (MIME), JSON and XML payloads, HTTP Basic authentication headers, JWT tokens, and data URLs that embed an image directly inside HTML or CSS. Base64 is an encoding, not encryption — anyone can decode it, so never use it to hide secrets.

The URL-safe variant (RFC 4648 §5) replaces + with - and / with _ and usually drops the = padding so the result can be placed in URLs, file names and cookies without escaping. JWTs use this form. The decoder on this page accepts both variants and tolerates missing padding, so you can paste a JWT segment directly.

How to use this tool

Type or paste text and it is encoded as you type. Text is treated as UTF-8, so Chinese, emoji and any other Unicode characters round-trip correctly — a common bug in naive implementations that use btoa() directly. Tick URL-safe to get the -/_ alphabet without padding. Click File to pick any file: images, PDFs, fonts or archives are read locally and encoded; for images the output is a complete data URL you can paste straight into an <img src> or a CSS background.

To decode, switch to Decode and paste Base64 (a full data URL also works). If the result is valid UTF-8 text it is shown in the output box; if it is binary, the tool detects common formats (PNG, JPEG, GIF, WebP, PDF, ZIP), previews images inline, and lets you download the decoded file. Swap moves the output back into the input so you can verify a round-trip in one click.

Privacy and limits

Files never leave your computer. They are read with the browser's File API, encoded in memory and shown to you; nothing is uploaded. Because everything runs client-side, the practical limit is your device's memory: files of tens of megabytes work fine, though the output text box becomes slow to scroll. For very large files, download the result instead of copying it.

Background: a text-only world

Base64 grew out of the constraints of early email. SMTP was designed for 7-bit ASCII text, so attaching a binary file meant translating it into printable characters first; uuencode did this in the 1980s, and the MIME standard (RFC 2045, 1996) defined the Base64 alphabet still used today. RFC 4648 (2006) later collected the variants: standard Base64, the URL- and filename-safe form, and Base32/Base16. The 3-bytes-to-4-characters ratio is why encoded data is exactly 4/3 the original size plus padding — a cost that mattered on dial-up and still matters for images inlined into CSS.

Where it is used

Email attachments are still Base64 under the hood. Data URLs embed small images and fonts directly into HTML and CSS to save a request — compress the image first, because Base64 adds 33% on top of whatever size you feed it. HTTP Basic authentication sends username:password as Base64 (not encrypted — always use HTTPS). JWT tokens are three URL-safe Base64 segments joined by dots; the header and payload decode to JSON. Kubernetes Secrets, cloud IAM policies, percent-encoded URLs that carry Base64 values, SHA-256 digests in Subresource Integrity attributes, SAML assertions, PEM certificates (the block between BEGIN and END lines) and binary fields inside JSON APIs all use it because these systems can only carry text. When you meet a long string ending in = or containing only letters, digits, + and /, it is almost certainly Base64, and pasting it here is the fastest way to find out what it holds.

Frequently asked questions