Base64 Encoder / Decoder

Base64 turns arbitrary text or binary data into an ASCII-safe string, using an alphabet of 64 characters (A-Z, a-z, 0-9, plus two more) that survives being pasted into places that don't handle raw binary or every Unicode character cleanly — HTTP headers, data URIs, authentication tokens, and config files. It is fully reversible: decoding produces exactly the original bytes back.

Everything happens in your browser. Base64 payloads frequently contain credentials or personal data — an API key, a JWT, a basic-auth header — so a converter that posts your input to a backend is a bad habit. This one has no backend to post to.

Encoding uses the browser's own UTF-8-aware APIs, which means emoji and non-Latin scripts round-trip correctly rather than producing mojibake — a common failure with hand-rolled or older Base64 utilities that assume Latin-1 input.

Decoding here is deliberately lenient: it accepts standard and URL-safe Base64 interchangeably and re-pads truncated input automatically, so you don't need to know which variant produced a string before pasting it in.

Standard vs. URL-safe Base64 alphabets

There are two Base64 alphabets in common use, and mixing them up is the most common decode failure elsewhere: standard Base64 uses + and /, while the URL-safe variant replaces those with - and _ so the string survives being placed directly in a URL without further encoding. The URL-safe toggle above switches the encoder between the two; decode on this page accepts either automatically, so you don't need to match it manually.

Missing padding breaks decoding — elsewhere

Standard Base64 pads its output with trailing = characters to a multiple of 4, and some systems (JWTs, some URL-safe contexts) strip that padding before transmitting it. A decoder that insists on padding will reject an otherwise-valid unpadded string, which looks like corruption but is really just a missing = or two — this page's decoder re-pads automatically, but a stricter decoder elsewhere may not.