How Base64 Config Encoding Works

Overview

Base64 is an encoding, not encryption: it maps arbitrary bytes onto 64 printable characters so that binary or newline-separated data survives copy-paste, chat apps and web pages. Two places in the proxy ecosystem use it constantly. VMess share links base64-encode their JSON body, and many subscriptions base64-wrap the whole config list, turning many lines into one opaque-looking string.

What the encoding actually does

Base64 processes input in 6-bit groups, so every 3 bytes become 4 characters. Two consequences matter in practice:

• Output length is roughly a third larger than input.
• Padding with = aligns the input to a multiple of 3 bytes; many share links omit the padding, and tolerant decoders restore it before decoding.

URL-safe variants swap + and / for - and _.

Decoding safely

Decoding never executes anything - it only reveals text you should inspect before trusting. A reasonable workflow:

1. Paste the link into the config parser, which decodes and explains each field.
2. Or use the standalone base64 decoder for the raw payload.
3. Check what appeared: a vmess:// link should decode to JSON with add, port, id and ps fields; a subscription should decode to a list of scheme:// URIs.
4. Re-encode with the QR generator if you want to move a config to a phone by scanning.

Pitfalls

• Broken padding - lines copied from forums often lose trailing = characters; re-padding fixes them.
• Double encoding - some feeds wrap twice; decode again if the first result still looks like base64.
• Encoding is not secrecy - anyone can decode the credential inside; treat shared configs as public knowledge.

Limitations

HiddenIO indexes public sources and cannot guarantee that decoded endpoints work or are safe; decoding is inspection, not endorsement.