Skip to content

Base64 Encoder & Decoder

Encode and decode Base64 and Base64URL with full Unicode support, plus file-to-data-URI conversion for images. Runs offline — nothing is ever uploaded.

Plain text

Base64

Result appears here as you type.

File to data URI

images, fonts, anything

Files are read locally in this tab — nothing is uploaded.

About the Base64 Encoder & Decoder

Base64 represents arbitrary bytes using 64 printable ASCII characters, so binary data can travel through channels that only accept text — HTTP headers, JSON string fields, email bodies, data URIs, git patches. It is an encoding, not encryption: anyone can decode it in one step, and it makes data roughly 33% larger, since every three input bytes become four output characters.

You will run into Base64 constantly without choosing it: it is how HTTP Basic Auth credentials are carried in an Authorization header, how the header and payload segments of a JWT are packed, how images get inlined as data: URIs in CSS and HTML, and how binary attachments survive being embedded in JSON, XML or MIME email. Recognizing it on sight — a run of letters, digits, +, / and trailing = padding — is a basic debugging skill.

This converter handles the full Unicode range in both directions, which naive implementations do not. The browser's built-in btoa() throws on any character above U+00FF, so it breaks on emoji, accented letters and CJK text the moment you try to encode them directly. Here the input is converted to UTF-8 bytes first, so "héllo 👋" round-trips correctly instead of throwing InvalidCharacterError.

It also supports Base64URL — the padding-free variant that swaps + and / for - and _ — which is what JWTs, OAuth state parameters, and any other value embedded directly in a URL use. Standard Base64's +, / and = characters all have special meaning inside a URL and would otherwise need percent-encoding on top, which is exactly the problem Base64URL exists to avoid.

  • Unicode-safe encoding and decoding via UTF-8, including emoji and CJK — no InvalidCharacterError on non-Latin1 input
  • Standard Base64 and URL-safe Base64URL, with padding handled automatically
  • Swap button to feed the output straight back in as input, to confirm a round-trip in two clicks
  • File to data URI conversion for images, fonts, PDFs and other binaries, read entirely in-tab
  • Live byte-size readout on both panes, so you can see the ~33% size cost of encoding as you type
  • Nothing leaves your browser — no network request is made for any input, text or file

How to use it

  1. Choose a direction: Text → Base64 to encode, or Base64 → Text to decode.
  2. Paste your content into the left pane; the result appears immediately on the right as you type.
  3. When encoding for a URL or a JWT, tick URL-safe to get the - and _ alphabet without padding.
  4. To convert a file — an image, font or any other binary — use Choose file and copy the resulting data: URI.
  5. Press Swap to move the output into the input and reverse the direction — useful for confirming a round-trip or continuing a chain of transformations.

Real-world use cases

Backend & API developers

Decode the Authorization: Basic header your framework's HTTP client sent to confirm the exact credentials on the wire, or build a data: URI for a small binary payload without writing a script for a one-off check.

Frontend developers

Turn a small icon, font or SVG into a data: URI to inline directly in CSS or an <img src>, avoiding an extra network request for assets too small to be worth their own file.

QA & test engineers

Decode a Base64 fixture or captured request body from a bug report to read the actual payload, instead of squinting at an opaque string in a ticket or HAR file.

DevOps & platform engineers

Decode a Kubernetes Secret's data field, a base64-encoded CI/CD environment variable, or a Docker Compose value that arrived pre-encoded, without dropping to a terminal for a single base64 -d.

Security & AppSec engineers

Peel back Base64 layers in a suspicious payload, cookie or JWT segment during triage — while remembering, as the FAQ below stresses, that Base64 provides zero confidentiality on its own.

Examples

Encoding text

Input
hello world
Output
aGVsbG8gd29ybGQ=

The trailing = is padding to a multiple of four characters. Base64URL omits it.

Basic authentication header

Input
demo:s3cret
Output
Authorization: Basic ZGVtbzpzM2NyZXQ=

Base64 provides no security here whatsoever — Basic auth is only safe over HTTPS, because the credentials are trivially recoverable from this string.

URL-safe output

Input
subjects?/all
Output
c3ViamVjdHM_L2FsbA

Standard Base64 would produce c3ViamVjdHM/L2FsbA==, whose / and = characters need escaping inside a URL. Base64URL avoids that entirely.

Decoding a JWT segment

Input
eyJhbGciOiJIUzI1NiJ9
Output
{"alg":"HS256"}

This is the header segment of a JWT, which is just Base64URL-encoded JSON. Paste any JWT segment here to inspect it, or use the dedicated JWT Decoder for the full token including signature verification.

Common errors

MessageCauseFix
InvalidCharacterError: Failed to execute 'atob'The input contains characters outside the Base64 alphabet — often a stray newline, quote or an already-decoded string.Remove surrounding quotes and whitespace. If the string uses - and _, it is Base64URL and must be converted first.
InvalidCharacterError: Failed to execute 'btoa'Encoding a string containing characters above U+00FF with the raw browser API.Convert to UTF-8 bytes first with TextEncoder. This tool does that automatically.
Decoded output is mojibakeThe bytes were decoded as the wrong character set, usually Latin-1 instead of UTF-8.Decode as UTF-8. If the source really was Latin-1, re-encode it correctly at the source.
Invalid base64 padding / lengthThe string was truncated, or padding was stripped by a URL-safe encoder.Pad the string with = until its length is a multiple of four. This tool applies that automatically.
"Decoded bytes are not valid UTF-8 text"You pasted Base64 that represents binary data — an image, font or other non-text file — into the text decoder, which assumes the decoded bytes are meant to be read as a string.Use the file tool instead: it is built for binary, and for the reverse direction (file → Base64) rather than decoding an arbitrary binary string back to a downloadable file.

Frequently asked questions

Is Base64 encryption?

No. It is a reversible encoding with no key involved — anyone can decode it in one step. Never use it to protect passwords, tokens or personal data; it provides zero confidentiality.

What is the difference between Base64 and Base64URL?

Base64URL replaces the + and / characters with - and _, and usually drops the = padding. Those substitutions matter because +, / and = all have special meaning inside URLs and would otherwise need percent-encoding. JWTs, OAuth state parameters and most URL-embedded tokens use Base64URL specifically because of this.

Why does Base64 make my data bigger?

Every three bytes become four characters, so the encoded form is about 33% larger, plus any padding. That overhead is the cost of representing arbitrary binary data in a text-only channel — it's not a bug in this tool, it's inherent to the encoding.

Can I convert Base64 to an image?

If you have the image file, use the file converter above: it reads the file and produces a complete data: URI you can drop straight into an <img src> or a CSS url() — no decoding step needed, since the data URI itself contains the encoded image. Pasting a raw Base64 string of image bytes into the text decoder will fail, because that path assumes the decoded bytes are meant to be read as UTF-8 text, not rendered as an image.

Does this work with emoji and non-English text?

Yes. Input is converted to UTF-8 bytes before encoding, so emoji, accents and CJK characters round-trip exactly. The browser's own btoa() would throw InvalidCharacterError on all of these.

Is my data uploaded anywhere?

No. Encoding, decoding and file reading all happen locally in your browser tab. There is no server involved, so credentials, internal payloads and unreleased assets are safe to paste or drop here.

Why do I see = signs at the end of some Base64 strings but not others?

The = characters pad the output to a multiple of four characters, which standard Base64 requires. Base64URL — used by JWTs and URL parameters — conventionally omits this padding, since the decoder can reconstruct it from the string's length.

Is there a size limit on what I can encode or convert?

Text encoding and decoding handle anything you can reasonably paste into a browser tab. The file converter is bounded by available memory, since the whole file is read and base64-encoded in the tab — for very large files (hundreds of MB+), a command-line tool like base64 or openssl will be faster and lighter.

Last updated