About this tool
A browser-based encryption workbench: Base64 / Base32 / Hex encoding, MD5 through SHA-512 digests, HMAC signatures, AES-256 and XTEA symmetric ciphers, plus the Chinese national standards SM2 / SM3 / SM4. Pick an algorithm, paste your input, get the result.
Every operation runs inside the page. Input, keys and generated key pairs are never sent to a server, and no account is required.
25 algorithms, four different jobs
These get mixed up constantly โ encoding treated as encryption, digests used to store passwords. Sorting them by purpose makes the choice obvious.
- Encoding (Base64 / Base32 / Hex / URL / Binary / Morse / ROT13): reversible, no key, just another representation. Ciphertext going into a URL or JSON usually needs a Base64 wrapper on top.
- Digests (MD5 / SHA-1 / SHA-256 / SHA-384 / SHA-512 / RIPEMD-160 / CRC-32): one-way. Use them for integrity checks and signature comparison, never for storing passwords.
- HMAC (HMAC-SHA1 / SHA256 / SHA384 / SHA512): a keyed digest โ proves integrity and authenticity. This is what payment and open-platform APIs actually use.
- Symmetric ciphers (AES-256-GCM / AES-256-CBC / XTEA-CBC): one key for both directions. GCM authenticates the ciphertext, so prefer it for new systems; CBC has broader compatibility but needs an explicit IV and padding.
The national standards: SM2, SM3, SM4
The SM family is not simply "the Chinese AES" โ three algorithms, three separate standards:
- SM4 (GM/T 0002, GB/T 32907): a block cipher with a 128-bit key and 128-bit block, the symmetric workhorse. CBC and ECB modes here, with PKCS#7, zero or no padding, hex output.
- SM3 (GM/T 0004, GB/T 32905): a 256-bit hash, the counterpart to SHA-256. Hashes are one-way, which is why there is no "decrypt SM3" button.
- SM2 (GM/T 0003, usage spec GM/T 0009): a 256-bit elliptic-curve public-key algorithm โ encrypt with the public key, decrypt with the private key (signing too). Public keys are accepted in 130-character (leading 04) or 128-character form, and the ciphertext layout can be C1C3C2 (newer default) or C1C2C3 (common in older implementations).
You supply the keys, and only you hold them
SM4 keys and IVs are used exactly as typed โ no derivation, no padding to length. A malformed key is rejected outright rather than silently replaced, so the ciphertext matches what your server or openssl produces. The "random" button generates a key locally and drops it into the field.
The page does not transmit your input anywhere. Access logging records that the page was opened and that an action ran, but never the key, the plaintext or the ciphertext.
On a shared machine, clear the fields when you are done. And production private keys should not be pasted into any web page โ this one included.
Frequently asked questions
- Why does the SM4 key have to be 32 hex characters?
- SM4 is a 128-bit block cipher: 128 bits = 16 bytes = 32 hex characters. The IV is also 16 bytes. One character short, one too many, or a stray space is rejected rather than producing plausible-looking ciphertext that will never decrypt.
- Why does SM2 decryption return nothing?
- Nine times out of ten the ciphertext layout is wrong: the newer standard is C1C3C2, while many older systems and Java defaults emit C1C2C3. Switch the dropdown and retry. If that fails, confirm the key pair matches and the public key still starts with 04.
- Why canโt SM3, MD5 or SHA be decrypted?
- They are one-way by design: any input collapses into a fixed-length fingerprint and the process cannot be reversed. So-called "MD5 decryption" sites are just dictionary lookups, which only work on weak passwords. For passwords use bcrypt, scrypt or Argon2 โ salted, and deliberately slow.
- AES-GCM or AES-CBC โ which one?
- Use GCM for new systems: it authenticates as it encrypts, so a single flipped bit makes decryption fail without a separate HMAC. Keep CBC for legacy interop only โ and make sure the IV is random and never reused, otherwise it leaks patterns in the plaintext.
- Will the output match the openssl command line?
- Yes. SM4 output is raw hex ciphertext, ready for openssl enc -sm4-cbc โ pass the key and IV with -K / -iv as hex so openssl skips password derivation. AES-CBC works the same way. For SM2 interop, make sure both sides agree on the C1C3C2 layout.
- Is Base64 encryption? Does it protect anything?
- No. Base64 maps bytes onto 64 printable characters and anyone can reverse it in one line of code. It solves transport safety, not confidentiality. Use AES or SM4 when secrecy matters, and Base64 only as a final wrapper when ciphertext must travel inside a URL, JSON or email body.