Table of Contents
A Base64 encoder decoder shows encoding in action, but it does not make data secret. Three tools that look similar cause three different kinds of security mistake. Base64 is used as if it were encryption, and secrets are posted in plain sight. A hash is used as if it were encryption, and people expect to ‘decrypt’ it. A JWT is treated as if it were secret, and sensitive data is put in its payload. Each mistake comes from confusing encoding, fingerprinting, and signed claims. This article separates them, with the practical rules that prevent each mistake.
In short: Base64 is encoding, not encryption: it represents binary data in ASCII text and is reversible. A hash is a fixed-size fingerprint: the same input always gives the hash, and a tiny change gives a different one. A JWT has Base64-encoded parts, header, payload, and signature, and its payload is not secret, so never put sensitive data in it.
Base64: encoding, not encryption
Base64 represents binary data – an image, a file, a byte string – using 64 ASCII characters (A-Z, a-z, 0-9, + and /, with = as padding) so it can be included in JSON, URLs (with a URL-safe variant), email, and other text systems. The encoding is fully reversible and standardised, which is the point: any system can decode it without a key.
That reversibility is also the warning. Encoding a password in Base64 does not protect it. Anyone who sees the string can decode it in seconds with the ToolSpark Base64 tool or any other decoder. If data needs to be secret, it needs encryption with a key, not encoding. Base64 is appropriate when the problem is transport (binary data in a text system), not secrecy.
Base64 also has a cost: 4 characters for every 3 bytes, about 33% overhead. Embedding a 100 KB image as Base64 in HTML or CSS makes roughly 133 KB of text. That is sometimes worth it to avoid an extra request, and often not. For images, Article 8’s format choice usually matters more than Base64: a smaller WebP file, embedded or not, beats a large PNG embedded as Base64.
Hashing: a fingerprint, not a locked box
A cryptographic hash function takes input of any size and produces a fixed-size output. SHA-256 always produces 256 bits, usually shown as 64 hexadecimal characters, whether the input is one word or a whole book. The same input always gives the same hash. Changing one character gives a completely different hash. And for a strong hash, you cannot practically work backwards from the hash to the input.
That makes hashes ideal for integrity: publish a file’s SHA-256 hash alongside the file, and anyone can verify the download was not altered by recomputing the hash and comparing it. It makes hashes poor for storing passwords directly: a plain hash of a common password can be looked up in a rainbow table. Passwords need a slow, salted password-hashing function designed for that job, plus a strong random password from a generator – not a fast hash like MD5 or SHA-256 alone.
Choose the algorithm by purpose: SHA-256 or SHA-384/SHA-512 for general integrity and security use today; avoid MD5 and SHA-1 for security, even if they still appear in legacy systems for non-security checksums. And always say which algorithm produced a hash when you share it – a hash without its algorithm is a fingerprint without a label.
JWT: three parts, one signature, no secrecy
A JSON Web Token has three Base64-encoded parts separated by dots: header, payload, and signature. The header says how it was signed (for example HS256 or RS256). The payload carries claims: who the token is for, when it expires, what it is allowed to do. The signature is computed over the header and payload with a secret key (HS256) or a private key (RS256/ES256), and it proves the token was issued by the key holder and has not been altered.
Because the payload is only Base64-encoded, anyone with the token can decode and read it. Do not put passwords, personal data, or anything sensitive in a JWT payload. Do not share a JWT in a screenshot, a URL that gets logged, or a public bug report. And check expiry: a token that never expires is a credential that never expires, which is a design flaw, not a convenience.
To debug a token, paste it into the ToolSpark JWT Decoder and read the header and payload – but do so only with a test token, never with a production token that grants real access. A decoder that runs in your browser is safer for this than pasting a real token into a random website, but the safest test token is one you generated for testing and can revoke.
A checklist before you ship
- If it must be secret, encrypt it with a key. Encoding is not encryption.
- If it must be verified as unchanged, hash it with SHA-256 or stronger, and label the algorithm.
- If it must prove who issued it, sign it, and keep the signing key secret – the token itself is not the secret, the key is.
- If it is a password, use a dedicated password-hashing function and a strong random password, not a fast hash.
- If it is a token, set a short expiry, store it safely, and never put sensitive data in its payload.
Use the ToolSpark Base64, Hash, HMAC, and JWT tools to learn and debug these concepts, with test data first. The tools explain the concepts; your key management, expiry policy, and data handling decide whether the system built on them is actually secure. For strong random passwords, use the Password Generator.
Frequently Asked Questions
Is Base64 encryption?
No. Base64 is encoding: it represents binary data in ASCII text so it can travel in text systems. Anyone can decode it. Never use Base64 to hide a password, token, or secret.
Why is Base64 output larger than the input?
Because it uses 4 ASCII characters to represent every 3 bytes, so output is about 33% larger, plus padding. That overhead matters when embedding images in code.
What is a hash?
A fixed-size fingerprint of data. The same input always gives the same hash; a tiny change gives a completely different hash; and you cannot practically reverse a strong hash to recover the input.
Is MD5 still safe?
Not for security purposes. MD5 and SHA-1 are broken for collision resistance. Use SHA-256 or stronger for integrity and security use, and use a dedicated password-hashing function, not a plain hash, for passwords.
Is a JWT secret?
No. A JWT’s payload is Base64-encoded, not encrypted, so anyone with the token can read its claims. Its security comes from the signature, which proves it was issued by someone holding the signing key, and from keeping the token itself safe.
Community Reviews & Discussion
Be the first in the community to share a tip, workflow suggestion, or review for this tool!