Base64 Decoder

Decode Base64 strings back to plain text. Supports standard and URL-safe Base64.

Base64 Input
0 chars0 bytes
Decoded Text
{ }
output will appear here

Where you will encounter Base64

Base64 strings appear in almost every layer of a web application. These are the five places developers most commonly need to decode them:

JWT tokenseyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.xxxxx

A JWT has three Base64URL-encoded segments separated by dots: header, payload, signature. Decoding the first two reveals the algorithm and claims. The signature segment cannot be decoded to meaningful text — it is a cryptographic hash.

HTTP Basic Auth headersAuthorization: Basic dXNlcjpwYXNzd29yZA==

The string after "Basic " is a Base64-encoded "username:password" pair. Decoding it reveals the credentials in plain text. This is why Basic Auth must always be used over HTTPS.

Data URIs in HTML/CSSsrc="data:image/png;base64,iVBORw0KGgo..."

The part after the comma is Base64-encoded binary. Decoding it gives the raw bytes of the image or file. You'll see these in inline SVGs, embedded fonts, and favicon data URIs.

API responses{ "content": "SGVsbG8sIHdvcmxkIQ==" }

Many APIs encode binary fields (images, documents, certificates) as Base64 strings in JSON. GitHub's REST API returns file contents as Base64; Google APIs use it for attachment data.

Email source (MIME)Content-Transfer-Encoding: base64 SGVsbG8=

Email attachments and non-ASCII body text are Base64-encoded per RFC 2045. When you view raw email source (View > Show Original in Gmail), the attachment data is Base64 with 76-character lines.

How to recognise a Base64 string

Not every random-looking string is Base64. These four signals together give a strong indication:

Character set

Only A–Z, a–z, 0–9, +, / (standard) or -, _ (URL-safe)

Padding

Ends with = or == in standard Base64; no padding in URL-safe

Length

Standard Base64 length is always a multiple of 4

Density

High information density — no spaces, punctuation, or recognisable words

Common decode errors and how to fix them

These four errors cover the vast majority of failed decodes. Each shows the problematic input, what it should look like, and why the error occurs.

Padding mismatchmost common
✗ broken
SGVsbG8
✓ fixed
SGVsbG8=

Standard Base64 output length must be a multiple of 4. If it isn't, = padding is missing — usually because the string was copied from a URL-safe source (JWT, URL parameter) that strips padding. Enable URL-safe mode in the settings panel, or manually append = until the length is divisible by 4.

Wrong variant (URL-safe vs standard)
✗ broken
SGVs-bG8_dGhpcw
✓ fixed
SGVs+bG8/dGhpcw==

URL-safe Base64 uses - and _ where standard Base64 uses + and /. If you paste URL-safe Base64 into a standard decoder it fails with an "invalid character" error. Toggle "URL-safe" in the settings panel to decode this variant automatically.

Whitespace or line breaks inside the string
✗ broken
SGVs bG8=
or  SGVs
bG8=
✓ fixed
SGVsbG8=

Email and MIME-encoded Base64 includes newlines every 76 characters per RFC 2045. Our decoder strips all whitespace before decoding, so you can paste MIME-formatted Base64 directly without cleaning it up first.

Decoding binary data as text
✗ broken
← garbled output like: ÿØÿàJFIF
✓ fixed
← encode the file, not its Base64 representation

If your Base64 string represents a binary file (image, PDF, archive), decoding it as text produces garbage — the bytes are valid but not valid UTF-8 text. Use a file-aware decoder or check whether the API intends the value to be read as text.

Related tools

  • Base64 Encoder — Encode text or files to Base64 for APIs, data URIs, and JWT segments.
  • JSON Formatter — Pretty-print JSON payloads that embed Base64 fields so you can read structure clearly.

Frequently asked questions

What does Base64 decoding do?

Base64 decoding reverses the encoding process — it takes a Base64 string and reconstructs the original text or binary data. The decoder converts each Base64 character back to its 6-bit value, reassembles the 6-bit groups into bytes, and outputs the original content.

How do I tell if a string is Base64-encoded?

Base64 strings only contain A–Z, a–z, 0–9, +, / (or - and _ for URL-safe). They are padded with = to reach a length that is a multiple of 4. The length is always divisible by 4 in standard Base64. If a string matches this pattern and looks random, it is almost certainly Base64.

Why does my decode output look like garbage?

Two likely causes: (1) the Base64 string represents binary data (an image, PDF, or compressed file) rather than text — decoding binary as UTF-8 produces unreadable output; (2) you are using the wrong variant — standard decoder on URL-safe input, or vice versa. Toggle URL-safe mode in the settings panel.

What is padding and why does it matter?

Base64 groups input into 3-byte chunks. If the input is not a multiple of 3 bytes, the output is padded with = to reach a multiple of 4 characters. Without correct padding the decoder cannot determine where the real data ends. URL-safe Base64 strips padding, so you may need to re-add = characters before decoding.

Can I decode a JWT token here?

Yes — paste one of the first two dot-separated segments (header or payload) into the decoder. For example: eyJhbGciOiJIUzI1NiJ9 decodes to {"alg":"HS256"}. Make sure URL-safe mode is on, since JWT uses Base64URL. Do not paste JWTs containing sensitive claims into tools you do not trust.

Why does pasting a full JWT fail?

A JWT is three Base64URL segments joined by dots (header.payload.signature). The tool decodes a single segment at a time. Paste only the header (before the first dot) or payload (between the dots) — not the full token string with dots included.

Is it safe to paste sensitive Base64 data here?

Yes. Decoding runs entirely in your browser using the native atob() API. Nothing is sent to any server. You can confirm this by opening DevTools → Network while using the tool — there are no outbound requests.