Developer Tools guide
Encoding, hashing and encryption: know what happened to the data
Unreadable-looking output is not automatically protected data. Base64, percent encoding, a SHA-256 digest and encrypted ciphertext can all look unfamiliar, but they solve different problems. Start by asking whether the transformation is meant for transport, comparison or confidentiality.
Recognize the layer you actually have
Base64 represents bytes with a restricted alphabet, commonly including letters, digits, + and / with = padding. Percent encoding represents selected bytes as % followed by hexadecimal digits, as in %20 for a space. A data URL adds a media-type prefix around its payload; it is not simply raw Base64.
Base64url uses a different alphabet convention from ordinary Base64. JWT segments use base64url, so use a token-aware decoder instead of assuming every Base64 textbox accepts the same input. SnakTool’s text Base64 tool targets standard Base64 and UTF-8 text.
A URL component is not a whole URL
When placing user text inside a query parameter, encode that component, not the entire final URL. Encoding the separators of an already assembled URL can turn its structure into literal data. SnakTool’s URL tool follows encodeURIComponent/decodeURIComponent behavior.
A plus sign is not universally a space. Form-encoded data may use + for a space, but decodeURIComponent does not perform that form-specific substitution. Decode according to the format that produced the string instead of applying replacements blindly.
Count the layers before decoding again
A percent sign itself encodes as %25. Thus %2520 can become %20 after one decode and a space after a second. The second step is correct only if the original value actually had two layers. Unexpected double decoding can change the meaning of paths or input.
For standard Base64, output length is approximately four characters per three input bytes, with padding as needed. It is not compression. Non-ASCII text uses multiple UTF-8 bytes for many characters, so count bytes rather than visible letters when estimating size.
Encoding a password or private document does not protect it. Handle an encoded secret as a secret and use appropriate cryptography when confidentiality is the goal.
Hashing answers a different question from encoding
A cryptographic hash maps exact input bytes to a fixed-size digest and is not designed with a general reverse operation. A SHA-256 digest shown as hexadecimal has 64 hex characters regardless of whether the input was a short word or a much longer text.
Matching a digest can support integrity checking when the reference digest is trustworthy. It does not encrypt the original, and a plain checksum does not authenticate a publisher if an attacker can replace both the content and its published checksum.
Fast SHA hashes are not password storage
SHA-256 and SHA-512 are designed to be fast. That is useful for checksums but also lets attackers test password guesses quickly. Password storage needs a purpose-built password hashing scheme with salts and suitable work parameters through maintained security libraries.
Calling a hash one-way does not make a weak password unguessable. Attackers usually hash candidate passwords and compare results rather than trying to mathematically reverse the digest.
Encryption is for recoverable confidentiality
Encryption is appropriate when authorized software or a recipient must recover protected data using the correct key or credential. Encoding does not provide that secrecy, and hashing is not a substitute because its normal purpose is not later recovery.
Choose the encryption mechanism for the actual system and threat model. Do not invent a protection scheme by combining Base64 with a hash simply because the result looks obscure.
| Operation | Recover original? | Secret required? | Typical purpose |
|---|---|---|---|
| Base64 / percent encoding | Yes, by decoding | No | Representation or transport |
| Cryptographic hashing | No general reverse operation | No | Digest comparison or security protocol component |
| Encryption | Yes with the appropriate scheme/key | Yes | Confidentiality |
Unwrap in reverse order
For the synthetic text ???, UTF-8 Base64 is Pz8/. Encoding that as a URL component produces Pz8%2F. To recover the text, percent-decode first, then Base64-decode. Reversing those steps sends percent signs to a Base64 parser.
A data URL adds a media-type prefix outside the Base64 payload. Image bytes are not ordinary UTF-8 text; use the image encoder for that workflow rather than expecting the text decoder to display a picture.
- Input
- ???
- Method
- UTF-8/Base64 -> Pz8/ -> URL component encoding -> Pz8%2F
- Result
- Decode: Pz8%2F -> Pz8/ -> ???