Base64 Encoder

Encode and decode Base64 online for free. Convert text and files instantly.

✓ Free✓ No sign-up✓ Works in browser

Plain Text Input64 chars

What is Base64?

An encoding scheme that converts binary data into ASCII text. Used to safely transmit data in URLs, emails, and HTML.

Common uses

Images in CSS/HTML, email attachments, JWT tokens, storing binary data in JSON, and API data transfer.

Size note

Base64 increases data size by ~33%. For files, this is expected. Use it for compatibility, not compression.

How to Use This Tool

Choose Encode or Decode Mode

Toggle between Encode (text → Base64) and Decode (Base64 → text) using the mode buttons at the top.

Paste Your Input

Paste your plain text to encode, or paste a Base64 string to decode, into the left input panel.

Copy the Output

Click the Copy button next to the output panel to copy the result to your clipboard.

Related Tools

Frequently Asked Questions

What is Base64 encoding?

Base64 is a binary-to-text encoding scheme that converts binary data into ASCII characters. It is used to transmit binary data over text-based protocols like email or JSON APIs, and to embed images directly in HTML and CSS.

What is Base64 used for?

Common uses include: encoding binary data in JSON, embedding images in CSS as data URLs, encoding credentials in HTTP Basic Authentication headers, and storing binary data in XML or HTML.

Is Base64 the same as encryption?

No. Base64 is encoding, not encryption. It simply converts data to a different representation. Anyone can decode it instantly. Do not use Base64 to secure sensitive data — use actual encryption instead.

Why does Base64 use = padding at the end?

Base64 encodes every 3 bytes of input into 4 characters. When the input length is not a multiple of 3, padding characters (=) are added to make the output length a multiple of 4.

About Base64 Encoder

You need to embed a 2KB SVG logo directly inside a CSS data: URI so a Cloudflare Worker response avoids an extra round trip, or decode the x-hub-signature-256 header from a GitHub webhook to debug why your HMAC verification is failing. Base64 is the lingua franca for shoving binary into text — JWT payloads, SMTP attachments, data URIs, PEM-wrapped certificates, and half the OAuth flows on the internet. This tool encodes and decodes both text and files (images, PDFs, binary blobs up to a few MB) using the browser's native btoa/atob with correct UTF-8 handling via encodeURIComponent round-tripping, so a string containing emoji or accented characters does not silently corrupt. Upload an image and you get the exact data URI string ready to paste into an <img src> or a CSS background-image. Paste a suspiciously long string starting with eyJ and we will correctly identify it as likely a JWT before you accidentally decode it here instead of the jwt-decoder.

How it works

1
Text path uses btoa with a UTF-8 bridge
JavaScript's btoa only accepts Latin-1 bytes, so naively encoding a string with non-ASCII characters throws InvalidCharacterError. We route text through encodeURIComponent first to convert to URL-safe UTF-8 bytes, then unescape to turn each %XX into the raw byte, then btoa. The decode path reverses this with atob → escape → decodeURIComponent, round-tripping emoji and accented characters correctly.
2
File path uses FileReader with readAsDataURL
When you upload a file, the browser's FileReader API produces a data: URI with the base64 payload already embedded. We strip the prefix to show just the base64 string and preserve the MIME type for the copy-as-data-URI button. Files up to roughly 10MB work in practice; beyond that the synchronous string construction stalls the UI.
3
Validation catches common paste errors
A paste containing whitespace, newlines, or URL-safe variant characters (- and _ instead of + and /) is normalized before decoding so 'EyJhbGc=' pasted with a line break between segments still decodes. An input that is not valid base64 after normalization throws a specific error pointing at the first invalid character rather than a cryptic DOMException.

Pro tips

Data URIs are heavier than you think — measure first

Base64 encoding increases byte size by exactly 33% (3 raw bytes become 4 characters). A 10KB PNG becomes 13.3KB when inlined. Plus, data URIs cannot be cached separately by the browser — every page load re-downloads them inside the HTML. For assets used on one page only, inlining often wins; for a shared logo used on 50 pages, a separate cacheable request is faster on repeat visits. Measure both with Lighthouse before committing.

URL-safe base64 uses - and _ instead of + and /

Standard base64 uses + and / which break inside URLs without percent-encoding. JWTs, OAuth state tokens, and most modern tokenized URLs use the URL-safe variant (RFC 4648 section 5): + → -, / → _, and padding = is usually stripped. If you paste a JWT header here and see decode errors, manually replace - with + and _ with / first, or pad with = until length is a multiple of 4. The jwt-decoder tool handles this conversion automatically.

Never base64 a password for 'security'

Base64 is encoding, not encryption. Anyone with five seconds and any base64 tool (including this one) can reverse it. If you see base64 used in an HTTP Basic Auth header, that string is 'username:password' and is trivially reversible — the security comes entirely from TLS wrapping the whole request. For actually securing secrets in transit or storage, use AES-GCM, libsodium secretbox, or a KMS-backed envelope encryption scheme. Base64 is a transport format only.

Honest limitations

· Files larger than ~10MB may crash the tab because the full base64 string (33% larger than source) has to fit in a single JavaScript string in memory.
· Binary decode to raw file download is not yet supported — decode mode shows text output, so decoding a base64'd PNG back into an image requires manual download via a third tool.
· URL-safe base64 variant with - and _ is auto-normalized on decode, but encode output uses standard + and / — replace manually if your target requires URL-safe form.

Frequently asked questions

Why does my encoded string look different from what Node.js Buffer produces?

Almost always a newline issue. Node's Buffer.from(str).toString('base64') by default wraps output at 76 characters per line (MIME convention), while btoa produces a single unbroken line. To compare, run Node with Buffer.from(str).toString('base64').replace(/\n/g, '') or use the shorter Buffer.from(str, 'utf-8').toString('base64'). Another source of drift is string encoding: Node defaults to UTF-8, but if the input was read as Latin-1 or Windows-1252 the bytes differ for any non-ASCII character, producing a different base64 output.

How do I encode a binary file safely at scale?

For automation, do not use a browser tool. Use base64 (Linux/macOS), certutil -encode (Windows), or Buffer.from(fs.readFileSync(path)).toString('base64') in Node. The browser approach is fine for one-off debugging up to a few MB but cannot stream — the whole file loads into memory twice (as a Blob and as a string) which caps you at around 10MB on a modern laptop and under 2MB on a low-end phone. Pipelines moving GB of data should use a streaming base64 encoder like the sax-b64 npm package.

Is a base64 string ever ambiguous between text and binary?

Not on decode — the raw bytes are the raw bytes regardless. The ambiguity is interpretation: a base64 of 'Hello' decodes to five bytes 48 65 6c 6c 6f which your tool will render as text 'Hello' because those bytes are valid ASCII. The same five bytes could also be the start of a truncated PNG header in a different context. When you decode here and see garbled output, it usually means the source was binary (image, font, certificate) rather than text, and you need to treat the output as raw bytes not a string.

What is the actual overhead of base64 encoding?

Exactly 4/3 (33.3%) for the raw encoding, plus up to 2 bytes of = padding on the tail. A 1000-byte input becomes a 1336-byte base64 string (1000 * 4 / 3, rounded up to a multiple of 4). Gzip compression recovers most of that overhead when the data is transmitted compressed, because the base64 alphabet of 64 characters has predictable distribution. For data URIs inlined in already-compressed responses (gzipped HTML), the net wire overhead is closer to 5-10% rather than 33%, but RAM and parse cost on the client still pay the full 33%.

Why does decoding a JWT give me back a JSON string and then another base64 string?

Because a JWT is three base64-URL-encoded parts separated by dots: header.payload.signature. Decoding the whole thing here pastes the full token, which is not valid base64 because of the dots. Split on the dots first and decode each part individually: the header and payload each decode to JSON, the signature decodes to raw HMAC or RSA signature bytes. The jwt-decoder tool does this split automatically and formats the JSON, which is what you want unless you are specifically debugging the base64 encoding step itself.

Base64 sits underneath most developer credential workflows. JWTs decoded via the jwt-decoder use URL-safe base64 for header and payload, which is how a decoded payload becomes readable JSON you can then paste into the json-formatter for diffing. Secret material generated by the password-generator is often base64-encoded before landing in a Kubernetes Secret manifest (Kubernetes requires base64 in the data field). And when you are hunting for accidentally-committed secrets in a codebase, the regex-tester is where you build patterns like /[A-Za-z0-9+/]{40,}={0,2}/ to catch base64 blobs that might be AWS keys or private keys before they ship.