dev101.io

Base64 Encode / Decode

Encode and decode Base64 strings in your browser — UTF-8 safe, privately.

Loading tool…

How to use Base64 Encode / Decode

  1. Choose Encode or Decode at the top of the tool.
  2. Pick the Standard or URL-safe variant depending on where the Base64 will be used (URLs, filenames, JWTs → URL-safe; email, configs → Standard).
  3. Paste your raw text (Encode mode) or Base64 string (Decode mode) into the left pane.
  4. Watch the output pane update on every keystroke. In Encode mode, toggle Wrap at 76 chars if you need MIME-style line-wrapped output.
  5. Press ⌘/Ctrl + Enter to swap modes and feed the last output back as input — useful for quick round-trip sanity checks.
  6. Use Copy output to grab the result, or Share to produce a URL that restores your session.

Base64 Encode / Decode

A single-input, live-preview utility for converting text to Base64 and back. Paste, pick a mode, copy — no sign-up, no uploads, no server round-trip. The entire transform runs in your browser using native TextEncoder, TextDecoder, btoa, and atob, which means the tool keeps working offline once the page is cached.

Why a dedicated Base64 tool

Base64 is the lingua franca of every developer workflow that needs to move arbitrary bytes through a text-only channel: data URIs in CSS, JWT headers and payloads, basic-auth credentials, SMTP attachments, webhooks that refuse binary bodies, Kubernetes secrets, iOS configuration profiles, and a thousand other corners of the stack. Most online Base64 converters either POST your input to a logging server, wrap the conversion behind an "API key" paywall, or silently corrupt non-ASCII text because their authors copied the naive btoa(input) snippet from Stack Overflow without testing it on an emoji.

This tool ships Base64 encoding and decoding as a client-side transform with three quiet but important guarantees: UTF-8 correctness, variant tolerance, and zero outbound network traffic. If your input is a session cookie, a private API key, or a chunk of log output mentioning a customer email, the last thing you want is another service in the chain of custody.

Encode to Base64

Encode mode turns raw text — including emoji, accented Latin, CJK ideographs, and newline-heavy multi-line content — into a Base64 string. The tool pipes your input through TextEncoder to produce UTF-8 bytes before the Base64 step, which is the detail that naive btoa(input) gets wrong. A string like "café" contains the code point U+00E9, encoded in UTF-8 as two bytes (0xC3 0xA9); the raw btoa built-in sees that as a single code point it doesn't know how to handle and throws.

Two toggles shape the encoded output:

  • Standard vs URL-safe. Standard Base64 (RFC 4648 §4) uses the alphabet A–Z a–z 0–9 + / with = padding. URL-safe Base64 (§5) substitutes - for + and _ for /, and by convention drops the trailing = because the length is inferable. Use standard for MIME, email, and anywhere the output is quoted or enclosed. Use URL-safe for JWTs, OAuth tokens, URL paths, filenames, and HTTP headers.
  • Wrap at 76 characters. Off by default. When on, the encoder inserts a \n every 76 characters — the MIME canonical line length. Turn this on when pasting Base64 into an email body, a .eml file, or a PEM block. Leave it off for everything else; line wraps tend to break JSON string literals and URL fragments.

Decode from Base64

Decode mode accepts Base64 input in whatever variant it arrived as. The decoder normalises -/_ to +//, auto-pads missing = characters, and strips surrounding whitespace including the MIME line-wrap newlines the encoder might have inserted. The result is UTF-8 decoded text, with invalid UTF-8 byte sequences surfaced as a typed error rather than quietly replaced with replacement glyphs.

Clear error messages catch the three common decode failures:

  • Illegal characters. Anything outside the Base64 alphabet — a stray @, a double-encoded space — produces a precise error pointing at the alphabet violation rather than throwing a cryptic InvalidCharacterError.
  • Impossible length. Base64 strings have length ≡ 0, 2, 3 (mod 4). A length of one more than a multiple of four cannot encode any whole number of bytes and is rejected with a "not a valid multiple of 4" message.
  • Non-UTF-8 payload. If the decoded bytes are not valid UTF-8 (for example, binary data that was never text to begin with), the tool says so. For arbitrary-bytes use cases, a future file-base64 tool will handle download/upload directly.

What this tool deliberately doesn't do

  • Binary file encoding. This is a string tool. The sibling Base64 File Encoder ships separately and handles uploads, downloads, and data-URI wrapping.
  • MIME multipart parsing. Paste one Base64 body at a time; for parsing full email envelopes, use a dedicated MIME tool.
  • Base32 / Base58 / Ascii85. Each alphabet gets its own tool — no hidden flags to bite you.

Privacy promise

Every byte of your input stays in your browser. No analytics on input, no server logging, no third-party scripts in the transform path. The Share button encodes state into the URL fragment, which browsers never send to servers by design, so shared links preserve the same privacy guarantee.

Related tools

Frequently asked questions

Why does naive `btoa` break on emoji like 🔥 and accented characters like café?

The browser's built-in `btoa` function was specified in the 1990s for Latin-1 byte strings and throws `InvalidCharacterError` on any JavaScript code point above `0xFF`. Emoji (🔥 is U+1F525), CJK ideographs, and even Latin accents outside Latin-1 all trigger the exception. This Base64 tool pipes input through `TextEncoder` first to produce proper UTF-8 bytes, then Base64-encodes those bytes, so every Unicode code point round-trips cleanly.

When should I use URL-safe Base64 instead of standard Base64?

Use URL-safe Base64 (RFC 4648 §5) whenever the output travels through a URL path, query string, filename, or HTTP header where `+`, `/`, or `=` would be reserved, percent-encoded, or confused with a path separator. JWTs, OAuth tokens, and most modern web APIs use the URL-safe alphabet with `-` and `_` and typically omit the trailing `=` padding. For MIME email bodies, TLS certificates, or anywhere the output is wrapped in quotes, the standard alphabet is the right default.

What do the `=` characters at the end of Base64 output mean?

Base64 encodes every three input bytes as four output characters. When the input length is not a multiple of three, the encoder pads the final group with one or two `=` characters so the output length stays a multiple of four. A single `=` means the source was two bytes short of a group; `==` means one byte short. The URL-safe variant omits the padding because the length is recoverable from context — this decoder auto-pads missing `=` characters before decoding.

Is my input sent to your servers?

No. The entire Base64 encode and decode transform runs locally in your browser using `TextEncoder`, `TextDecoder`, `btoa`, and `atob`. There is no encode or decode API endpoint, no analytics on input content, and no third-party script in the chain between your clipboard and the output. The Share button encodes state into the URL fragment (`#…`), which browsers never send to servers by design, so even shared links keep your payload private.

Related tools