What is the main difference?
| Operation | Main purpose | Reversible | Secret key required | Typical output | Common examples |
|---|---|---|---|---|---|
| Encoding | Represent data for transport or storage | Yes | No | Text or bytes in another syntax | Base64, hexadecimal, percent encoding |
| Hashing | Produce a fingerprint for integrity or comparison | No practical inverse | No | Fixed-size digest | SHA-256, SHA-384, SHA-512 |
| Encryption | Protect content from unauthorized reading | Yes, with the correct key | Yes | Ciphertext, often with nonce and tag | AES-GCM, ChaCha20-Poly1305 |
The visual appearance does not define the operation. Base64 text can look random, but anyone can decode it. A hexadecimal hash can look similar to encrypted bytes, but it cannot restore the source. Ciphertext can be represented as Base64 for transport, which means one value can pass through encryption and encoding in sequence.
What is encoding?
Base64 is a common binary-to-text encoding. RFC 4648 defines Base16, Base32, and Base64 alphabets, padding rules, and canonical behavior. Base64 helps carry arbitrary bytes through text-oriented systems. It does not hide those bytes.
A Base64 encoder groups input bits and maps them to a restricted character alphabet. Padding can complete the final group. Variants can use different alphabets. The URL-safe Base64 alphabet replaces characters that create problems in filenames or URLs. A receiving system must know which variant and padding rules apply.
Hexadecimal encoding represents each byte with two base-16 characters. It is easy to inspect and copy. It doubles the byte count before surrounding text overhead. Base64 usually uses less text than hexadecimal for the same bytes. It still increases size compared with the original binary.
Percent encoding is another representation. URLs use it to represent characters that do not fit safely in a particular component. HTML entities represent special characters in markup. Character encodings, including UTF-8, map text characters to byte sequences. Each process solves a compatibility problem rather than a secrecy problem.
You can inspect simple input with the Base64 encoder and decoder. Do not paste passwords, production keys, private tokens, or regulated data into any tool without confirming its processing model. Browser execution reduces some transmission risks, but it does not replace endpoint security or organizational policy.
Reproduce Base64 output before debugging real data
Open the Base64 encoder and decoder, choose Encode, and keep the standard alphabet. Enter Hello without a trailing line break. The result is SGVsbG8=. Decode that result to recover Hello.
Now add one line-feed character after Hello. The encoded result changes to SGVsbG8K. Both results are correct for their respective input bytes. A copied terminal line, editor setting, or extra space can therefore explain different output.
| Input bytes in hexadecimal | Meaning | Standard Base64 |
|---|---|---|
48 65 6c 6c 6f |
Hello without a line break |
SGVsbG8= |
48 65 6c 6c 6f 0a |
Hello followed by a line feed |
SGVsbG8K |
Base64 encodes bytes, not an abstract text value. Agree on a character encoding before comparing non-ASCII text across tools. UTF-8 and legacy encodings can produce different bytes for the same visible character. Do not infer the byte encoding from how the input looks.
For a failed comparison, inspect extra whitespace, character encoding, alphabet, and padding before changing the data. Standard Base64 and Base64url use different characters for two alphabet positions. Follow the receiving protocol’s padding rules. RFC 4648 defines these alphabet and padding distinctions.
What is hashing?
A cryptographic hash function accepts input of variable length and returns a fixed-length digest. The same input produces the same digest under the same algorithm. A small input change should create a substantially different digest. Security uses require resistance to input recovery and deliberate collisions. Finding another input with the same digest must also remain impractical.
NIST FIPS 180-4 specifies the Secure Hash Standard. It includes SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. These algorithms produce different digest lengths and have different implementation details. “SHA-2” names the family rather than one output size.
File publishers often provide a digest beside a download. You can hash the downloaded bytes and compare the result. Matching digests show that your bytes match the bytes used for the published digest. The comparison does not prove who published the digest. You still need an authentic channel, a signature, or another trust mechanism.
The SHA-2 digest calculator can calculate common SHA-2 results for controlled data. The all hashes generator can display several algorithm outputs for comparison. Multiple outputs do not make a weak algorithm strong. Select an algorithm according to the security requirement and relevant standard.
Hashes are not unique identifiers
A fixed-length digest represents an unlimited set of possible inputs. Collisions must therefore exist mathematically. A secure hash makes useful collisions computationally difficult to find. It does not make them impossible.
Do not use a digest as proof that two different sources are identical in every security context. Assess the algorithm, input construction, adversary, and consequences. Deprecated hashes can remain useful for accidental corruption checks, but they may fail against an active attacker.
The hash analyzer can infer likely algorithms from length and syntax. It cannot prove which algorithm created a value. Different algorithms and encodings can produce similar-looking strings. Context remains necessary.
Hashing passwords needs a password-specific design
A general-purpose hash is deliberately fast. That property helps file verification and content addressing. It also lets an attacker test many password guesses quickly.
Password storage needs a password hashing or key derivation function with a unique salt and a deliberate cost. Modern systems also need controlled parameters, secure comparison, migration planning, and protection for backups. NIST SP 800-63B gives current authenticator guidance, including requirements that affect stored password verifiers.
A salt does not need secrecy. It prevents the same password from producing the same stored verifier across accounts and defeats simple precomputed tables. A pepper is a separate secret and creates different operational requirements. Neither term changes Base64 into encryption or makes a fast unsalted digest suitable for passwords.
A checksum is not always a cryptographic hash
Checksums detect common accidental changes. CRC algorithms are effective for transmission errors and storage corruption. They do not usually resist deliberate manipulation. Cryptographic hash functions target stronger adversarial properties.
State the requirement before selecting a method. Use a checksum for accidental error detection when its model fits. Use a cryptographic hash or message authentication code when an attacker can modify data. Use a digital signature when receivers must verify origin and integrity through public-key cryptography.
What is encryption?
Encryption transforms plaintext into ciphertext under a key. Decryption restores the plaintext with the required key. Secure encryption needs more than an algorithm name. It needs correct key generation, mode selection, nonce handling, authentication, implementation, storage, rotation, and access control.
NIST FIPS 197 specifies the Advanced Encryption Standard. AES operates on 128-bit blocks and supports 128-bit, 192-bit, and 256-bit keys. AES alone does not define how an application safely encrypts a long message. A mode of operation supplies that construction.
Authenticated encryption modes protect confidentiality and detect unauthorized changes. AES-GCM is a common example. The authentication tag lets decryption reject modified ciphertext or associated data. A design that encrypts without authentication can leak information or accept attacker-controlled changes, depending on the mode and protocol.
NIST SP 800-38D defines Galois/Counter Mode and GMAC. Its nonce requirements are critical. Reusing a nonce with the same GCM key can break security. A user-entered initialization vector can repeat across sessions. The surrounding system must prevent unsafe reuse.
You can use the AES encryption tool for learning and controlled transformations. Do not treat a browser utility as a complete key-management system. Production encryption requires a reviewed protocol and protected key lifecycle.
Symmetric and asymmetric encryption
Symmetric encryption uses a shared secret key. The same key, or directly related keys, perform encryption and decryption. AES is symmetric. It is efficient for substantial data, but participants need a safe way to share and store keys.
Asymmetric encryption uses a public and private key pair. The public key can support encryption for the private-key holder in suitable schemes. Public-key cryptography also supports digital signatures, but signing is not the same operation as encryption.
Many real protocols combine both types. Public-key methods establish or protect a temporary symmetric key. Symmetric authenticated encryption then protects the application data. The protocol also authenticates participants, binds context, and prevents replay.
The keys, certificates, and JWT collection provides related inspection tools. A certificate binds identity data to a public key through a signature chain. A JSON Web Token is a data format that can be signed or encrypted depending on its construction. Base64url segments alone do not make a token secret.
Encryption at rest and in transit
Encryption at rest protects stored data under a storage threat model. Full-disk encryption can help when a powered-off device is lost. Database field encryption can restrict some data access paths. Backups, logs, exports, search indexes, and cached copies need separate review.
Encryption in transit protects communication between endpoints. TLS is the common web example. It does not protect data after a legitimate endpoint decrypts it. Browser extensions, compromised devices, server logs, analytics systems, and authorized users can still access plaintext.
“Encrypted” is incomplete without scope. Ask what data receives protection, where encryption begins, where decryption occurs, who controls keys, and which attackers remain in scope.
Where do message authentication codes fit?
A message authentication code, or MAC, protects integrity and authenticity between parties that share a secret key. HMAC combines a cryptographic hash with a specific keyed construction. It is not plain hashing and does not encrypt content.
NIST FIPS 198-1 specifies the Keyed-Hash Message Authentication Code. A receiver with the key can verify that a message and tag match. The receiver cannot use the tag to recover the message. Anyone with the shared key can also create valid tags. HMAC therefore does not provide public verification like a digital signature.
Use a MAC when the message can remain visible but unauthorized changes must be detected between key-sharing participants. Use authenticated encryption when the message also needs confidentiality. Use a digital signature when verification must work with a public key and signer accountability matters.
Where do digital signatures fit?
A digital signature uses a private key to sign data and a public key to verify the signature. It targets authenticity, integrity, and in some systems non-repudiation properties. It does not inherently hide the signed content.
Signatures usually operate on a structured representation or digest. Correct canonicalization matters because two byte sequences can represent similar human-readable data. Protocols must also bind algorithm choices, context, identifiers, and expiry rules.
NIST SP 800-175B explains federal guidance for cryptographic standards. Application developers should use maintained libraries and established protocols instead of assembling primitives from isolated tool outputs.
How can the operations work together?
A secure application often uses several transformations in a defined order. Consider an encrypted message transported in JSON:
- The application serializes the plaintext into an exact byte sequence.
- An authenticated encryption algorithm creates ciphertext and a tag under a key and nonce.
- Base64url encodes binary fields so JSON can carry them safely.
- The receiver decodes Base64url and then performs authenticated decryption.
- The receiver rejects the message if authentication fails.
The encoding layer provides representation. The encryption layer provides confidentiality and integrity. Reversing only the encoding reveals ciphertext, not plaintext. Skipping authentication can invalidate the security design.
Another workflow can hash a public file, sign the digest, and Base64-encode the signature. The hash supports an efficient fixed-size input. The signature binds the digest to a private key. Base64 makes the signature easy to transmit as text. Each operation has a distinct promise.