Base64 Decode Online

Online Base64 Decode and Encode

This Base64 decode online tool encodes and decodes Base64 in real time in your browser: paste plain text or a Base64 string, switch encode/decode mode, and copy the result. Processing is local—handy for API payloads, Data URIs, and config fields.

Quick decode: Switch to decode → paste a Base64 string (e.g. aGVsbG8sIHdvcmxk) → copy the plaintext output.

Quick encode: Switch to encode → enter text → copy the Base64 output.

The format is defined in RFC 4648. In the browser, see also MDN: btoa() / atob().

What Is Base64?

Base64 maps binary data to 64 printable ASCII characters—a common binary-to-text encoding. In front-end work, small images are often embedded as Base64 Data URIs to save HTTP requests.

The alphabet is 0-9, A-Z, a-z, plus + and /. In URLs, / conflicts with paths, so URL-safe Base64 uses - and _ instead (JWT uses this variant).

Every 3 bytes of input become 4 encoded characters, so output is about one-third larger. See the Theory tab for padding rules.

10101101, 10111010, 01110110
00101011, 00011011, 00101011, 00110110

Common Use Cases

• Decode Base64 from API responses or logs
• Data URIs for small inline images in HTML/CSS
• JWT: Header and Payload use Base64URL (use our JWT Decoder for full token debugging)

FAQ (essentials)

Is Base64 an encryption algorithm?

No. Base64 is a reversible encoding scheme for carrying binary data in text-only channels—it does not provide confidentiality (see RFC 4648).

Why does Base64 decoding show garbled text?

Often UTF-8 multi-byte text was decoded as Latin1, or the URL-safe alphabet was used by mistake. This tool decodes as UTF-8.

Is online Base64 decoding safe?

Processing is local in the browser; input is not uploaded. Still protect secrets on shared devices.

Encoding steps

1. Convert data to uint8 binary.
2. Group the binary into 6-bit units (64 possible values, 0–63).
3. Map each 6-bit index to the corresponding Base64 character from the lookup table.
4. Pad the output so its length is a multiple of 4 using =.

See RFC 4648 Section 4 for padding rules: 1 byte input → 2 chars + ==, 2 bytes → 3 chars + =.

API

REST API

This site provides a public API for Base64:

# Encode
$ curl -L devtool.tech/api/base64?s=hello

# Decode
$ curl -L devtool.tech/api/base64?s=5bGx5pyI&d

Live Demo

JavaScript

Use btoa/atob in the browser and Buffer in Node. You can also use base64-js.

const base64 = {
  encode (v: string) {
    return isBrowser ? btoa(v) : Buffer.from(v).toString('base64')
  },
  decode (v: string) {
    return isBrowser ? atob(v) : Buffer.from(v, 'base64').toString()
  }
}

Bash

On macOS/Linux you can use the base64 command:

# Encode
$ echo hello | base64
aGVsbG8K

# Decode
$ echo aGVsbG8K | base64 -d
hello

FAQ

How do I decode Base64 online?

Switch to decode mode, paste your Base64 string (padding = allowed), and read the UTF-8 output. Processing stays in your browser per RFC 4648.

Q: How much larger does data get after Base64 encoding?

Base64 encodes every 3 bytes of input into 4 characters, so the output is roughly 33% larger than the original. If the input length isn't a multiple of 3, = padding characters are appended. In some contexts (e.g., MIME email), line breaks are also inserted, which adds a bit more overhead.

Q: Is Base64 an encryption algorithm?

No. Base64 is an encoding scheme, not encryption. Its purpose is to represent binary data as printable ASCII text so it can be safely transmitted over text-only protocols such as email or JSON. The encoding is fully reversible—anyone can decode it without a key. If you need to protect data confidentiality, use a proper encryption algorithm like AES.

Q: What's the difference between URL-safe Base64 and standard Base64?

Standard Base64 uses + and / as the 62nd and 63rd characters. Both have special meanings in URLs (+ is interpreted as a space, / is a path separator). URL-safe Base64 replaces + with - and / with _, making the output safe for use in URLs and filenames. JWT (JSON Web Token) is a well-known example that uses URL-safe Base64.

Q: Why would you embed images as Base64?

Embedding small images as Base64 data URIs in HTML or CSS eliminates the extra HTTP request for each image, which can speed up page loads. This technique works well for tiny icons and decorative graphics. However, because Base64 increases the data size by about 33%, it's generally not recommended for images larger than a few KB—the bloated HTML/CSS file would outweigh the benefit of saving a request.

Q: What do the = signs at the end of a Base64 string mean?

Base64 processes input in groups of 3 bytes. When the input length isn't evenly divisible by 3, padding is needed. If 1 byte remains, two == are appended; if 2 bytes remain, a single = is appended. The = characters carry no data—they simply mark the padding so the decoder knows the original length. They are ignored during decoding.

Q: Why does Base64 decoding show garbled text?

Often the input was UTF-8 multi-byte text (e.g. Chinese) decoded as Latin1 via atob() alone. Decode to bytes first, then interpret as UTF-8. This tool handles UTF-8 on decode. If still wrong, check for URL-safe alphabet, missing padding, or wrong encoding (hex, etc.).

Q: How do I encode or decode Chinese text?

Encode the string as UTF-8 bytes, then Base64-encode those bytes. Reverse on decode. This tool supports Chinese in both encode and decode modes.

Q: Is online Base64 decoding safe?

Encoding and decoding run locally; input is not uploaded. Still avoid pasting production secrets or personal data on shared screens.

Q: How is Base64 different from URL encoding?

Base64 maps binary to 64 printable characters (~33% size increase), per RFC 4648. URL percent-encoding escapes unsafe URL bytes as %XX, per RFC 3986. They solve different problems and are not interchangeable.

Standard vs URL-Safe Base64

Padding Rules

Input is processed in 3-byte groups, producing 4 output characters:

1. Input length is a multiple of 3: output length is a multiple of 4, no =
2. 1 byte left: 2 characters + ==
3. 2 bytes left: 3 characters + =

RFC 4648 Section 4 describes this from the raw-byte perspective; encoded output must always pad to a multiple of four characters.

vs URL Encoding and Hex

• Percent-encoding (URL encoding): unsafe bytes become %XX per RFC 3986
• Hex: 2 characters per byte (200% size), no alphabet mapping
• Base64: 3 bytes → 4 characters (~33% overhead), good for binary-in-text

Unicode and UTF-8

btoa() in JavaScript only accepts Latin1 strings. Unicode text (e.g. Chinese) must be UTF-8 bytes before encoding. This tool encodes UTF-8 bytes and decodes back to UTF-8 to avoid mojibake. See FAQ «How to encode Chinese».

References

• RFC 4648 — Base64
• MDN: Base64