Base64, Hex & URL Encoding

What is it?

Base64 encodes bytes as A–Z a–z 0–9 + / (often ending in =). Hex encodes each byte as two 0–9 a–f characters. URL/percent encoding writes bytes as %XX. Each has a recognisable shape you can spot on sight.

Why it matters

Recognising an encoding by its alphabet and shape is faster than trial and error: a long A–Za–z0–9 string ending in == is Base64; %2F%2E is URL encoding; a run of hex pairs is hex.

Where you see it

A PowerShell -enc argument is Base64 (UTF-16); a URL parameter shows %XX; a config blob may be plain hex. Recognise, then apply the matching From-operation.

What normal looks like

The encoding's alphabet matches its type, and decoding it yields readable, meaningful output (a URL, a command, a script).

What suspicious looks like

Not the encoding itself — but a wrong guess (treating hex as Base64) yields garbage. The garbage is the signal to try a different From-operation.

How analysts investigate

Read the alphabet: only 0–9a–f in pairs → hex; A–Za–z0–9+/ with = padding → Base64; %XX sequences → URL. If decoding gives garbage, your guess was wrong — try another.

Common beginner mistakes

Confusing hex and Base64 (they use different alphabets).
Forgetting a PowerShell -enc Base64 is UTF-16 (decode, then Remove null bytes / Decode text).

Recognise the alphabet

  Base64:  SQBFAFgA...==      A–Za–z0–9+/ , '=' padding
  Hex:     69 65 78 20        pairs of 0–9 a–f
  URL:     %2Fadmin%3Fid%3D   %XX sequences
  match the alphabet → apply From Base64 / From Hex / URL Decode

Each encoding has a recognisable alphabet/shape; identify it, then apply the matching decode operation.

Quick check

You see 'JVBERi0xLjQ=' — long A–Za–z0–9 ending in '='. Which decode?

A quick self-check — it doesn't affect your XP or progress.