SoupCalc

UTF-8 Base64 Encoder and Decoder

UTF-8 Base64 Encoder and Decoder

This tool converts text to bytes using UTF-8 and represents those bytes with the standard Base64 alphabet. It can also reverse a canonical Base64 string into UTF-8 text. Processing happens locally in the browser; the tool does not intentionally send the entered text to a SoupCalc server.

How encoding works

RFC 4648 Base64 groups three bytes (24 bits) into four 6-bit values and represents them as four characters. The standard alphabet contains A–Z, a–z, 0–9, +, and /. One or two = characters pad the final group when its input contains fewer than three bytes.

Text needs a character encoding before it can become bytes. This implementation always uses UTF-8, which makes the result predictable for non-ASCII text. The decoder validates the standard alphabet, group length, canonical padding, and UTF-8 output instead of silently accepting malformed input.

Worked example

The six ASCII/UTF-8 bytes for Hello! encode to SGVsbG8h.

Unicode text follows the same byte-level rule. The UTF-8 bytes for 你好 encode to 5L2g5aW9. Decoding that exact value returns the original two Chinese characters.

Because three input bytes become four output characters, Base64 commonly increases size by roughly one third, with small inputs affected more by padding.

What the result means

Base64 is a transport representation for bytes. It is useful when a text-only field must carry byte data, but the receiver must know whether the decoded bytes represent UTF-8 text, an image, or something else.

This page is deliberately text-oriented. It decodes only values that produce valid UTF-8. It is not a general binary-file encoder, and it uses the standard alphabet—not the URL-safe Base64 alphabet that substitutes - and _ and may apply different padding conventions.

Limits and security

  • Base64 is not encryption and provides no confidentiality, authentication, integrity protection, or password hashing. Anyone with the value can normally decode it.
  • Do not paste secrets into an online tool unless you understand the execution environment. Local browser processing reduces network exposure but does not protect against browser extensions, compromised devices, copied history, screenshots, or other local access.
  • The decoder rejects whitespace, non-alphabet characters, misplaced or missing padding, noncanonical encodings, and byte sequences that are not valid UTF-8. Other tools may be more permissive, so acceptance elsewhere does not make a value canonical here.
  • Base64 does not compress data. For large files, use a file-aware workflow that preserves the original bytes and verifies integrity.

Sources

Editorial record

  • Author: SoupCalc Editorial Team
  • Method review: SoupCalc Engineering and Security Review
  • Last reviewed: August 10, 2026
  • Review scope: UTF-8 conversion, canonical RFC 4648 behavior, examples, browser data handling, and security boundaries