Base64 Encode and Decode Online, Client-Side

Base64 Encode and Decode converts arbitrary bytes to an ASCII string using the RFC 4648 alphabet, and reverses that string back to the original bytes. Text mode accepts a character encoding such as UTF-8; file mode reads an upload through the browser's FileReader and can emit a data: URI for embedding. Encoding is not encryption. Anyone who receives the string can decode it.

All encoding and decoding runs in your browser. Nothing you paste is sent to a server.

Encode text or a file to Base64

Encoding takes raw bytes and writes a string of A to Z, a to z, 0 to 9, plus, slash and padding =. Paste text or choose a file, select character encoding when the source is text, and read the output.

File mode suits small images and documents that must travel inside JSON, XML or email without a binary channel.

The output is safe for transport through systems that corrupt arbitrary binary, such as older mail gateways or copy-paste into XML. It is longer than the input by design. Invalid empty input produces no string; the tool waits for bytes before emitting characters.

Decode a Base64 string back to data

Decoding reverses the alphabet lookup, rebuilds the original bit stream and returns text or a downloadable file. Padding = characters at the end are significant: they mark how many bytes were in the final incomplete group. Characters outside the alphabet cause a clear error rather than a silent partial decode.

Whitespace is often ignored so strings copied from PEM certificates or MIME bodies still work. A string that looks like Base64 but uses the URL-safe alphabet needs the URL-safe decode mode, or hyphen and underscore will be rejected as illegal in the standard alphabet.

Understand how Base64 encoding works

Base64 processes input in blocks of three bytes (24 bits). Those 24 bits are split into four groups of 6 bits. Each 6-bit value is an index from 0 to 63 into the 64-character alphabet. Three input bytes therefore become four output characters.

Bytes:  [ byte1 ][ byte2 ][ byte3 ]
Bits:   aaaaaaaa bbbbbbbb cccccccc
Groups: aaaaaa aabbbb bbbbcc cccccc
Chars:  Char1  Char2  Char3  Char4

When fewer than three bytes remain, the encoder still emits four characters but adds padding so the decoder knows the original length. The bit regrouping is the entire algorithm; there is no checksum and no key.

Encode the word Dog step by step

The word Dog is three ASCII bytes, so it fills one Base64 group and encodes with no padding characters. The fixture output is RG9n. Walking the bytes to bits, regrouping into 6-bit indexes, and reading the RFC 4648 alphabet shows why those four characters appear and how any three-byte block follows the same path.

1. Write the bytes. D = 0x44 = 01000100 o = 0x6F = 01101111 g = 0x67 = 01100111

2. Concatenate 24 bits. 01000100 01101111 01100111

3. Split into 6-bit groups. 010001 000110 111101 100111

4. Convert each group to a decimal index. 17, 6, 61, 39

5. Look up the alphabet. Index 17 = R, 6 = G, 61 = 9, 39 = n

Result: RG9n. Decoding RG9n returns the three original bytes and the text Dog under UTF-8 or ASCII.

Understand padding with the equals sign

Padding appears when the byte count is not a multiple of three. One leftover byte produces two alphabet characters and two = signs. Two leftover bytes produce three characters and one =. The fixtures Do → RG8= and Dogs → RG9ncw== show both remainder cases beside the unpadded three-byte word Dog.

Input	Bytes	Encoded	Padding
Dog	3	RG9n	none
Do	2	RG8=	one =
Dogs	4	RG9ncw==	two =

Do is two bytes: 01000100 01101111. After 6-bit grouping there are only enough bits for three meaningful characters (RG8), and one padding = fills the fourth slot. Dogs is four bytes: a full three-byte group encoding as RG9n, then a one-byte remainder encoding as cw==. Removing padding by hand without adjusting the bit length breaks decoding; leave the = characters in place when pasting.

Read the Base64 alphabet

RFC 4648 defines 64 characters plus the padding mark =. Indexes 0 to 25 are A to Z, 26 to 51 are a to z, 52 to 61 are 0 to 9, index 62 is +, and index 63 is /.

Index 0 is A, not 0, which trips anyone who expects digits to lead the alphabet.

Index range	Characters
0 to 25	A to Z
26 to 51	a to z
52 to 61	0 to 9
62	+
63	/
padding	=

The calculator's alphabet panel lists the same table the encoder uses, so a suspicious character can be checked against the standard set. The full string is ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/.

Use the URL-safe Base64 variant

The URL-safe alphabet (base64url) replaces + with - and / with _. Padding may be omitted in some protocols. JSON Web Tokens use this variant so token segments can sit in URLs and HTTP headers without percent-encoding the plus and slash characters.

Standard and URL-safe strings are not interchangeable. Decoding a JWT payload with the standard alphabet fails on hyphens. The tool offers an explicit URL-safe mode for both encode and decode. Percent-encoding a URL is a different problem; use the URL Encode and Decode page when the goal is RFC 3986 escaping rather than Base64.

Account for the size increase

Every three bytes become four characters, so encoded length is about 4/3 of the input, a 33 percent increase before line breaks. Padding can add one or two extra characters on the final group. Data URIs and email attachments feel this cost quickly: a 300 KB image becomes roughly 400 KB of text.

encoded_length ≈ 4 × ceil(byte_length / 3)

Line wrapping at 76 characters, common in MIME, adds newline bytes on top. Prefer binary attachments or compressed formats when size matters; use Base64 when the channel genuinely cannot carry raw bytes.

Choose a character encoding

Base64 encodes bytes, not abstract characters. The same letters produce different bytes under UTF-8, UTF-16, Shift JIS or Big5. Decoding then interpreting with the wrong charset yields mojibake even when the Base64 layer was perfect, so the text mode charset must match the producer on encode and the consumer on decode.

Charset	Typical use
UTF-8	Default for modern text and APIs
Windows-1252	Legacy Western European text
UTF-16 LE / BE	Some Windows and Java payloads
Shift JIS	Older Japanese text
Big5	Older Traditional Chinese text

For the word Dog, ASCII and UTF-8 produce the same three bytes, so RG9n is identical. Non-ASCII text diverges. Pick the charset that matches the producer before encoding, and the same charset after decoding, or the round trip will look like a Base64 bug when the mistake is upstream.

Frequently asked questions

Summary

Base64 Encode and Decode maps bytes to the RFC 4648 alphabet in 6-bit groups and reverses the process locally in the browser. Dog becomes RG9n, Do becomes RG8=, and Dogs becomes RG9ncw==, illustrating padding for one- and two-byte remainders.

The URL-safe alphabet swaps +// for -/_, output grows by about one third, and character set choice decides which bytes the text mode feeds into the encoder. Nothing pasted is uploaded.