跳至內容
DevTools / Base64 編碼 / 解碼

Base64 編碼 / 解碼

Base64 turns arbitrary bytes into the 64 printable characters that survive every transport layer ever written — email bodies, HTTP headers, XML documents, JSON strings, database columns that only accept text. This converter encodes and decodes in both directions, supports the standard and URL-safe alphabets, handles multi-byte UTF-8 correctly rather than mangling non-Latin text, and previews an encoded image as a real data URL so you can see exactly what the browser will render.

完全在瀏覽器本機執行——不會上傳任何內容。

0 characters

結果
尚無內容

Image ⇄ Base64 / Data URL

或將檔案拖曳到此處

運作原理

The encoding is a fixed regrouping of bits, nothing more. Base64 reads the input three bytes at a time (24 bits) and re-slices those 24 bits into four 6-bit groups. Each 6-bit group maps to one of 64 characters — A-Z, a-z, 0-9, then + and / — producing four output characters for every three input bytes. When the input length is not a multiple of three, the final group is padded with = signs, which is why Base64 strings so often end in one or two equals characters.

That 3-to-4 relationship is why Base64 inflates data by roughly 33 percent: 3 bytes become 4 characters, 3 kilobytes become 4 kilobytes. The trade is deliberate. The output is guaranteed to contain no control characters, no quotes, no backslashes and no bytes above 127, so it can be embedded in a JSON string, a SQL literal or an HTTP header without any escaping at all.

A second alphabet exists because the standard one is hostile to URLs and filenames: + is interpreted as a space in a query string, and / is a path separator. URL-safe Base64 (RFC 4648 section 5) swaps those two characters for - and _ and usually drops the trailing padding. The two alphabets encode identical bytes; only the last two characters of the alphabet differ. Confusing them is the single most common cause of a signature that will not verify.

Decoding reverses the process: each character maps back to a 6-bit value, four values are concatenated into 24 bits, and those bits are split back into three bytes. Many decoders silently ignore invalid characters instead of failing, which is a real hazard — a truncated token copied from a log file will happily decode into plausible-looking garbage. This tool validates the input against the selected alphabet first and reports the offending character position.

常見應用情境

  • Embed a small logo or icon inline in a CSS or HTML file as a data URL to remove one HTTP request.
  • Inspect a data: URL copied out of a browser's network panel and recover the file it contains.
  • Decode the payload segment of a JWT in a system that has no dedicated JWT tool to hand.
  • Prepare a binary attachment for a SOAP or XML API that cannot carry raw bytes.
  • Convert a certificate or key file to the Base64 form expected by a config file or environment variable.
  • Diagnose a broken signature by confirming that the sender used URL-safe Base64 and the verifier expects the standard alphabet.

最後更新: 2026-10-14 — 正文以英文顯示，介面已完成翻譯。

常見問題解答

Is Base64 a form of encryption?

No, and treating it as one is a genuine security bug. Base64 is a reversible encoding with no key: anyone who intercepts the string can decode it in a single step. It hides data from a human reading over your shoulder, not from a machine. If you need confidentiality, encrypt first — for example with AES-GCM — and Base64 the ciphertext afterwards so it survives transport.

Why does my decoded text come out as garbled characters?

Non-Latin text is almost always the cause. Characters such as Chinese, Japanese, Arabic or an emoji occupy two to four bytes in UTF-8, and a decoder that assumes one byte per character will split them mid-sequence. This tool decodes to UTF-8 without a substitute-character fallback, so accented and CJK text round-trips exactly. If your output is still mangled, the original was probably encoded in a legacy single-byte codepage such as GBK or Latin-1.

What is the difference between standard and URL-safe Base64?

Only two characters and the padding. Standard Base64 uses + and /; URL-safe uses - and _ so the result can sit in a query string or a filename without being percent-encoded. Some implementations also strip the trailing = padding. The encoded bytes are identical, so if you are debugging an invalid-signature error, checking which alphabet each side used is the first thing to try.

How much larger does Base64 make my data?

About 33 percent before compression, because every three bytes become four characters. Padding rounds a short input up to the next multiple of four, so a one-byte input pays 300 percent. Base64 itself does not compress, but it is friendly to gzip and Brotli on the wire: the 64-character alphabet leaves plenty of statistical redundancy, and HTTP responses carrying Base64 text typically shrink by 70 to 80 percent.

相關工具