Encoding / Decoding

Base64 Encode / Decode

Encode or decode text using Base64.

Original text
Base64
Result will appear here

What is Base64 Encoding?

Base64 is an encoding scheme that represents binary data using 64 printable ASCII characters. It's commonly used to transmit binary data over text-based protocols (like HTTP, email), or to embed small data (like images as Data URIs) in URLs and HTML.

Features

  • Two-way conversion: Supports both encoding and decoding
  • Unicode support: Correctly handles UTF-8 encoded characters (including Chinese)
  • Real-time conversion: Results update instantly as you type
  • One-click copy: Quickly copy conversion results

Use Cases

  • Image Data URIs: Convert small images to embeddable Base64 strings
  • API Authentication: HTTP Basic Auth uses Base64 encoded credentials
  • Data Transfer: Transmit binary data within JSON
  • Email Attachments: Standard encoding for email attachments

Base64 maps every 3 bytes of input to 4 printable ASCII characters, so binary data can travel through text-only channels. It encodes UTF-8 text in the browser and decodes it back, including multi-byte CJK characters.

How the encoding works

Each group of 3 bytes (24 bits) is split into four 6-bit values, and each value indexes a 64-character alphabet of A–Z, a–z, 0–9, plus + and /. When the input length is not a multiple of three, the encoder pads with zero bits and appends = or == so the output length stays a multiple of four. That padding is structural, not part of the data: a decoder must tolerate it, and many strict decoders reject a payload whose length is not a multiple of four.

Why CJK text needs UTF-8 first

Base64 operates on bytes, not characters. A Chinese character occupies 3 bytes in UTF-8, so 世界 is 6 bytes and encodes to 8 Base64 characters. Browsers expose btoa(), which throws on any code unit above 0xFF; the reliable path is to run TextEncoder to get UTF-8 bytes, expand them to a byte string, then call btoa(). Decoding reverses this with TextDecoder. Skipping this step is the most common cause of "invalid character" or garbled output on non-ASCII input.

Base64 vs Base64URL

URL-safe variants replace + with - and / with _, and often drop the trailing padding, because + is decoded as a space in query strings and / changes path segments. JWT segments, many API tokens, and JSON Web Keys use Base64URL. A payload produced by standard Base64 that contains + or / will break if pasted into a URL unmodified, so check which alphabet the consumer expects before shipping.

Worked example

Encoding mixed ASCII and CJK text

Input 
hello 世界
Output 
aGVsbG8g5LiW55WM

The input is exactly 12 UTF-8 bytes: hello (5) + space (1) + two 3-byte CJK characters (6). Because 12 is a multiple of 3 there is no = padding, and the result is 16 characters long. Pasting the output into decode mode returns the original string byte for byte.

Limits and pitfalls

  • Base64 increases size by roughly 33% (4 characters per 3 bytes), which matters for large payloads and Data URIs embedded in CSS.
  • It is encoding, not encryption: anyone can decode it, so never use it to protect secrets.
  • Decoding requires valid UTF-8 for text output; binary payloads decode to bytes and should be handled as files, not strings.
  • Line breaks and whitespace inside a payload are illegal in strict implementations; strip them before decoding.

Related tools

Base64 tool or the tool beside it

SituationThis Base64 toolPick this instead
The payload is a PNG, PDF or ZIPDecoding passes the decoded bytes through a UTF-8 check, so a well-formed Base64 string of binary data still ends in the "Invalid Base64 string" message.File Base64 converter, which reads the file as a byte buffer. Switch to it as soon as the payload is not valid UTF-8 text.
The string ends up in a URL, a JWT or an object keyKeeps the standard alphabet, so + and / go straight into your string and break query parsing or path matching.Base64URL, for example Buffer.from(text, "utf8").toString("base64url"). Use it whenever the consumer is a URL, a JWT or a JSON Web Key.
A single byte is wrong and you must find itEvery 3 input bytes collapse into one 4-character block, so corruption stays inside its block and two payloads look alike at a glance.Hex tool, which prints byte offsets. Pick it when you are diffing two payloads instead of moving one.
The same job repeats for many files or in CIOne paste per round trip in the browser tab, with no scriptable entry point and no log of what was converted.The base64 command or python3 -m base64. Use them for batch runs; keep this page for inspecting a single value.
Mostly ASCII text that travels in a query stringA 3-byte group becomes 4 characters, and the resulting +, / and = still need percent-encoding on top.URL Encode tool, which percent-encodes the UTF-8 bytes directly. Shorter and readable while you are debugging a request.
The decoded result is JSON or XML you have to readStops at a plain string, so a payload cut off mid-object looks like ordinary text.Decode here, then paste the result into JSON Formatter. That second paste is what exposes a truncated payload.

One concrete scenario

Rescuing a JWT payload segment out of a bug report

A ticket pastes one segment of a token: 74 characters, no trailing =, and a - inside it. Those 74 characters are the Base64URL form of 55 bytes, and 4 times ceil(55 / 3) is 76, so two padding characters were stripped. Decode mode rejects it because atob has no - in its alphabet: map - and _ back to + and / first, then append == so the length is a multiple of four, which is what strict decoders such as Python also demand. A segment with remainder 1 when divided by four cannot be repaired by padding: the copy was truncated, so ask for the raw log line. The result is JSON; check it in JSON Formatter before calling the token broken.

Frequently Asked Questions

Why does Base64 output end with one or two "=" signs?
That is padding, which rounds the output length up to a multiple of 4. Base64 encodes 3 bytes into 4 characters: 1 leftover byte needs "==", 2 leftover bytes need "=". Padding carries no data, and some URL-safe variants omit it entirely.
Is Base64 a form of encryption?
No. Base64 is a keyless, fully reversible encoding — anyone can decode it. Use it to carry binary data as text, never to protect secrets; for confidentiality use AES or similar.
Why does my Chinese text decode as garbled characters in some tools?
Classic atob/btoa only handle Latin-1 bytes. This tool encodes the UTF-8 bytes of your text, so Chinese, emoji, and other non-ASCII characters round-trip correctly.

Content reviewed: