METHOD BEFORE OUTPUT
Cryptography tools should state what protection they actually provide
These 33 browser tools cover password creation, authentication codes, modern encryption, signatures, classical ciphers, hashes, checksums, token inspection, code transformation, and carefully labeled legacy compatibility. Every page starts with the underlying user task and the precise operation that produces its result. Encoding is never called encryption, a digest is never described as reversible, and decoding a JSON Web Token is kept separate from verifying its signature.
Ordinary inputs remain inside the current browser tab. Native Web Crypto handles AES-GCM, RSA, PBKDF2, HMAC, SHA digests, and cryptographic randomness. Small open-source libraries are loaded only for algorithms the browser does not expose, including SM2, SM4, RIPEMD-160, Keccak, SHAKE, bcrypt, and older compatibility formats. No password, private key, TOTP seed, plaintext, ciphertext, or result is sent to NexaCurrent for processing.
Modern protection needs authentication
The AES page uses AES-256-GCM, a fresh 96-bit IV, and a password-derived key with a fresh salt. GCM authenticates the encrypted text, so a wrong password or modified envelope fails instead of producing plausible garbage. The RSA page separates OAEP encryption from PSS signatures and limits the operation to short text because RSA is normally used to protect small session material rather than whole files.
TOTP seeds and private keys can grant access to real systems. The interface therefore treats them as secrets, never saves them as tool history, and gives visitors a clear reminder to clear the tab. Browser-generated keys are useful for testing and learning, but they are not certificates or substitutes for an organization's key-management process.
Hashes, MACs, and checksums answer different questions
SHA, Keccak, SHAKE, MD5, and RIPEMD-160 create deterministic digests. HMAC additionally uses a shared secret to authenticate a message. CRC-32 is designed to catch common accidental changes, not hostile tampering. MD5 and SHA-1 remain visible only where old formats require them, with a warning that their collision resistance is inadequate for modern signatures or security decisions.
Password storage is another separate problem. Fast general hashes are poor password verifiers because attackers can evaluate them cheaply. The htpasswd page defaults to bcrypt, while its SHA-1 output is explicitly marked as legacy compatibility. The password strength page estimates guess patterns but cannot know whether a password has been privately reused, stolen, or exposed by malware.
Legacy and classical tools are migration aids
Caesar, Vigenère, Hill, Rail Fence, ROT, repeating-key XOR, symbol substitution, and zero-width steganography are educational transforms. Their rules are public and their key spaces or patterns are easy to recover. Rabbit, RC4, DES, and Triple DES pages exist for controlled migration or old test fixtures; they direct new work to authenticated AES-GCM rather than presenting historical compatibility as current security.
Code packing and obfuscation can slow casual reading but cannot hide an API key shipped to a browser. The JavaScript decoder and unpacker accept only wrappers generated by this site and do not execute submitted source. Visitors should still review transformed code, restrict work to code they own, and use ordinary access control for genuine secrets.