Base64

Overview

Base64 is one of the most common encodings you will meet in CTFs and in everyday computing. It turns arbitrary binary data into a string of 64 "safe" printable characters so the data can travel through channels that only handle text — email bodies, URLs, JSON, HTML attributes, and configuration files. Recognizing and decoding Base64 is a foundational skill, because challenge authors constantly wrap flags, tokens, and file contents in it.

A crucial point up front: Base64 is encoding, not encryption. It hides nothing. Anyone can decode it with no key. If you see Base64, treat it as plain data in disguise, not as a secret that has been protected.

Learning objectives

• Explain what Base64 does and why it exists.
• Describe how three bytes map to four Base64 characters.
• Recognize the Base64 alphabet and the meaning of = padding.
• Decode Base64 by hand and with common tools, and explain why it offers no confidentiality.

Core concept

Computers store everything as bytes (8-bit values, 0–255). Many of those byte values are not printable characters — they may be control codes, null bytes, or symbols that break text formats. Base64 solves the problem of moving binary data through text-only channels by re-expressing the bytes using only 64 characters that are safe almost everywhere.

The standard Base64 alphabet is:

• A–Z → values 0–25
• a–z → values 26–51
• 0–9 → values 52–61
• + → 62
• / → 63
• = → padding (not a data value)

Because 64 is 2^6, each Base64 character represents exactly 6 bits of the original data.

How it works

Base64 works on the data in groups of three bytes (24 bits) and re-splits those 24 bits into four groups of six bits. Each 6-bit group (a value from 0 to 63) becomes one character from the alphabet above.

The step-by-step process:

1. Take 3 bytes of input = 24 bits.
2. Split the 24 bits into 4 chunks of 6 bits.
3. Convert each 6-bit chunk (0–63) to its alphabet character.
4. Repeat for the next 3 bytes.

Three bytes always become four characters, so Base64 output is about 33% larger than the input.

Padding

Input is not always a multiple of three bytes. Base64 handles the leftover with = padding:

• 3 bytes left → 4 characters, no padding.
• 2 bytes left → 3 meaningful characters + one =.
• 1 byte left → 2 meaningful characters + two ==.

So a Base64 string's length is always a multiple of 4 (in the padded form), and trailing = signals how many bytes the final group held.

Practical example

Encode the 3-byte string Man:

• ASCII codes: M = 77, a = 97, n = 110.
• In bits: 01001101 01100001 01101110 (24 bits).
• Re-split into six-bit groups: 010011 010110 000101 101110.
• As numbers: 19, 22, 5, 46.
• Map to the alphabet: 19 → T, 22 → W, 5 → F, 46 → u.

So Man encodes to TWFu. This is the classic textbook example, and you can verify it byte for byte.

Now an example with padding — the 2-byte string Hi:

• ASCII codes: H = 72, i = 105 → bits 01001000 01101001 (16 bits).
• Pad with zero bits to fill the final 6-bit group and add one =.
• The result is SGk=.

On the command line you can check these:

echo -n 'Man' | base64      # TWFu
echo -n 'Hi'  | base64      # SGk=
echo -n 'SGk=' | base64 -d  # Hi

The -n matters: without it, echo adds a trailing newline byte that changes the output.

Cybersecurity relevance

• CTF challenges frequently hand you a Base64 blob. Decoding it may reveal a flag directly, or reveal a file (many file types, including images, are transported as Base64).
• Data URIs, JWTs, and HTTP Basic auth all use Base64 (JWTs use a URL-safe variant; Basic auth encodes user:password as Base64 — which is why HTTPS matters, since Base64 credentials are trivially decoded, not protected).
• Recognizing Base64 in logs or traffic helps an analyst quickly reveal what data is actually being sent.
• Because it is reversible without a key, never rely on Base64 to protect secrets. It only makes data transport-safe, not confidential.

Common mistakes

• Confusing encoding with encryption. Base64 offers zero confidentiality; anyone can decode it instantly.
• Forgetting -n with echo, which appends a newline and produces a different, "wrong-looking" encoding.
• Dropping or adding = padding, which can corrupt the decode or make a valid string look invalid.
• Confusing standard and URL-safe alphabets — the URL-safe variant replaces + and / with - and _, so mixing them fails to decode.

Key takeaways

• Base64 represents binary data using 64 printable characters, mapping every 3 bytes to 4 characters (6 bits each).
• Trailing = is padding that marks a final group of 1 or 2 bytes; output length is a multiple of 4.
• Man → TWFu and Hi → SGk= are correct, verifiable examples.
• Base64 is a reversible representation, not encryption — it provides no secrecy at all.

Check your understanding

• Why does Base64 expand data by roughly one third, and how many characters does a 3-byte input produce?
• What does a trailing = (or ==) tell you about the original data length?
• Why is it wrong to say a Base64-encoded password is "protected"?