DES encrypt/decrypt in your browser: single DES, 3DES (2-key/3-key), ECB/CBC, PKCS#7 (Java's PKCS5Padding). Key lengths validated strictly — never silently truncated. Includes an equivalent OpenSSL command. Nothing is uploaded.
ECB encrypts equal blocks to equal ciphertext and leaks patterns — use it only to talk to a system that requires it.
—
The command contains the key you entered.
| Key (single DES) | 0123456789abcdef |
|---|---|
| Plaintext | 4e6f772069732074 |
| Ciphertext (ECB, no padding) | 3fa40e8a984d4815 |
Written and reviewed by the developers who build the crypto tools. Every ciphertext and byte count on this page is computed by the tool's engine and asserted by tests.
8 / 16 / 24 bytes Single DES: 8 bytes (56 effective bits). 3DES: 16 bytes (2-key) or 24 bytes (3-key). Nominal key material 112/168 bits; NIST security strength about 80/112 bits (SP 800-57). Auto-detected from the byte count; other lengths throw.
3fa40e8a984d4815 Key 0123456789abcdef, plaintext "Now is t" (hex 4e6f772069732074): single DES ECB without padding outputs 3fa40e8a984d4815.
8 bytes 8 bytes (16 hex digits), CBC only — ECB uses none. Distinct from AES's 16-byte IV.
= PKCS#7 For DES it is PKCS#7 — the same padding algorithm under its historical name (PKCS#5 only defined 8-byte blocks, which happens to be DES's).
Legacy interop only No. Single DES retired 2005; 3DES deprecated in SP 800-131A Rev.2 (2023). Legacy interop only — use AES-256 for anything new.
DES (Data Encryption Standard) is the symmetric block cipher the US standards body adopted in 1977, based on IBM's Lucifer design. It processes 64-bit (8-byte) blocks under a nominal 64-bit key with 56 effective bits, through 16 rounds of a Feistel structure.
3DES (TDEA, Triple DES) chains DES three times to patch the short key: C = E_K3(D_K2(E_K1(P))). The middle pass is a decryption so that K1=K2=K3 collapses the chain to single DES — a deliberate compatibility choice. The 2-key form (K3=K1) has about 112 effective bits and is the most common shape in legacy banking systems.
NIST retired single DES in 2005 (FIPS 46-3 notice) and deprecated 3DES in SP 800-131A Rev.2 (2023). The only reason they still exist is legacy interop: bank clearings, payment gateways and 90s/2000s Java/.NET/PHP systems still run DES-era crypto. New designs should use AES-256.
# OpenSSL single DES (legacy provider) openssl enc -des-ecb -provider legacy -provider default -K 0123456789abcdef -nopad # 3-key 3DES CBC + PKCS#7 (default provider) openssl enc -des-ede3-cbc -K <48 hex digits> -iv <16 hex digits> -base64 -A
8/16/24 bytes are auto-detected as single DES / 2-key / 3-key 3DES; anything else throws. Unlike CryptoJS's silent truncation or openssl enc -K's truncate-and-warn, wrong keys fail loudly — the top source of interop mismatches.
The test vector table at the bottom is derived by the same engine at build time, so crawlers read the reference value without running JS and the printed number can never drift from the interactive one.
Every parameter combination maps to an openssl enc command that reproduces the result on OpenSSL 3, including the legacy-provider flags for single DES. Send it to the other side to pin down parameter divergence.
DES-era Java getBytes() on a Chinese Windows JDK produces GBK. Both directions here accept GBK, so old-system Chinese plaintext needs no pre-conversion.
Pure TypeScript, zero dependencies, zero network requests. Keys and plaintext never leave the device; works offline once loaded. The only acceptable shape for a key-handling tool.
"DES" defaults to ECB + PKCS5Padding Cipher.getInstance("DES") equals DES/ECB/PKCS5Padding; "DESede" is 3DES but accepts only 24-byte keys — expand K1‖K2 to K1‖K2‖K1 for 2-key. PKCS5Padding is PKCS#7 for DES. Omitting the IV: encryption picks a random one (retrieve via getIV()), decryption throws "Parameters missing".
des-ede3-cbc / des-ede-cbc Algorithm names follow OpenSSL: des-ede3 is triple ECB, des-ede3-cbc is CBC. $options=0 (default) outputs Base64 text; OPENSSL_RAW_DATA for raw bytes. Short keys are silently zero-padded; an empty IV warns and then encrypts with a zero IV.
-des-ede3-cbc works by default Single DES needs -provider legacy -provider default (some builds omit legacy entirely). -K/-iv take hex; PKCS#7 by default, -nopad to disable. -K truncates overlong keys with a warning.
An 8-byte raw key (WordArray) works; wrong lengths are silently zero-padded or truncated (4 bytes padded, 10 truncated — no error). A string "key" runs key derivation (MD5 + random salt, Salted__-prefixed output, different every time). CBC with no IV is a TypeError crash, not a zero IV. TripleDES with an 8-byte key silently becomes single DES.
TripleDES defaults to CBC + PKCS7 TripleDESCryptoServiceProvider: Mode=CBC, Padding=PKCS7, Key of 16 or 24 bytes (DES takes 8). .NET rejects weak keys (parity is normalized first, then checked against the weak-key table — a zero key throws) while every other library accepts them. Watch this when migrating.
des.NewCipher gives the raw 8-byte-key block interface; you wrap it in cipher.NewCBCEncrypter etc. yourself. 3DES is des.NewTripleDESCipher (24 bytes). IV length is checked more strictly than in most languages.
Key 0123456789abcdef, plaintext (hex) 4e6f772069732074
3fa40e8a984d4815
The plaintext is the ASCII string "Now is t". This is the textbook FIPS 81 vector, and the table at the bottom of the page is computed at build time by the same engine — if your DES implementation does not produce this value for these inputs, it has a bug.
Key 0123456789abcdeffedcba9876543210 (16 bytes), IV fedcba9876543210, plaintext: DES interop test: order 20260927-0042
QmnMoewSecp7Z7cr/w3/4AjM9lpFo1swc4dfLNH5UkgCwU5n7WIdKA==
A 16-byte key is treated as 2-key 3DES (K1 = first 8 bytes, K2 = last 8, K3 = K1 — the EDE2 assembly). PKCS#7 over an 8-byte block is exactly what Java calls "PKCS5Padding" for DES: same scheme, only the block size differs.
Key 0123456789abcdef23456789abcdef010456789abcdef012 (24 bytes), IV fedcba9876543210, plaintext: hello des
DhDQX9sfxKOirZ8eyqT7Jg==
A 24-byte key is the full three-key EDE3: C = E_K3(D_K2(E_K1(P))). Of the three key lengths this is the only form with no degenerate equivalent — both 2-key and K1=K2=K3 collapse to weaker ciphers.
For Java DES/ECB/PKCS5Padding choose ECB + PKCS#7; for openssl enc -des-ede3-cbc choose CBC + PKCS#7. Old PHP mcrypt code typically uses Zero padding.
The byte count selects the cipher: 8 = single DES, 16 = 2-key 3DES, 24 = 3-key 3DES. Choose Hex, Text or Base64; the badge shows the real byte count and the detected shape. Wrong lengths throw — nothing is ever truncated.
ECB needs no IV. The IV must be exactly 8 bytes — 16 hex digits, not AES's 32. The Random button produces a fresh one.
Encrypting: enter text (UTF-8/GBK) or hex. Decrypting: paste Base64 or hex ciphertext. Results update as you type, with one-click copy and a round-trip check via the Decrypt-this button.
The collapsible panel gives an openssl enc command that reproduces the current result (key included; single-DES commands carry -provider legacy -provider default). Send it to whoever you are interoperating with — the fastest way to settle whose parameter is wrong.
A "DES key" of 32 hex characters is 16 bytes — that is 2-key 3DES, not single DES. Conversely, feeding a 24-byte key to a 2-key-only system fails too.
Key 0123456789abcdeffedcba9876543210 (16 bytes) with single DES selected → error "the key must be exactly 8 bytes"
The same key as 16 bytes (2-key 3DES) → decrypts cleanly
Java writes "PKCS5Padding" for DES but executes the PKCS#7 algorithm (PKCS#5 only ever defined 8-byte-block padding, which equals DES's block, so the name stuck). Selecting None or Zero against a JCE ciphertext always fails.
JCE `DES/ECB/PKCS5Padding` ciphertext decrypted as "no padding" → trailing garbage or a bad-padding error
Select PKCS#7 (Java PKCS5Padding) → clean output
DES's block is 8 bytes, so its IV is 8 bytes too. Pasting a 32-hex-digit IV from AES code fails the length check; an 8-hex-digit IV gets zero-padded and misread.
IV 00000000000000000000000000000000 (32 hex digits) → error "IV must be 8 bytes"
IV 0000000000000000 (16 hex digits) → accepted
Decrypting multi-block ciphertext with a wrong IV does not error — only the first 8-byte block is garbage, the rest decrypts fine (the IV only reaches block one, and the padding check lives in the last block). When you see "first few characters garbled, rest fine", check the IV before the key; single-block ciphertext instead breaks the padding and throws bad decrypt.
Multi-block ciphertext + wrong IV → first 8 bytes garbled, rest normal — misread as "wrong key"
Change only the IV (key untouched) → first block recovers, confirming the IV was the issue
-K keeps only the bytes it needs and prints a one-line warning that scripts swallow. When the other side says "the key is these 48 hex digits" but actually encrypted with the first 16, decrypting with the full key fails.
Shell: `-K <49 hex digits>` → "hex string is too long, ignoring excess" lost in the pipeline
Use this tool's equivalent command to generate a correct-length `-K`, then compare key bytes with the other side
The default OpenSSL 3 provider has no des-ecb/des-cbc; running it bare throws digital envelope routines::unsupported. Add -provider legacy -provider default, or use des-ede3 with K‖K‖K (algebraically single DES).
openssl enc -des-ecb -K … → Error: unsupported
openssl enc -des-ecb -provider legacy -provider default -K … (or des-ede3-ecb -K <K‖K‖K>)
Cipher.getInstance("DES/ECB/PKCS5Padding") output or openssl_encrypt(..., 'des-ede3-cbc', ...) output against this tool byte for byte before switching. 2-key/3-key shapes are detected from the key length, so there is nothing to guess.03 03 03) and pads a full block with a whole extra block — this is Java's "PKCS5Padding" for DES. Zero padding fills with 0x00 and is lossy when the plaintext genuinely ends in 0x00. None requires an exact multiple of 8.-provider legacy -provider default, and some builds (including Node's bundled OpenSSL) omit it entirely. 3DES (des-ede/des-ede3) stays in the default provider. This tool's pure-TS engine is unaffected.PKCS5Padding IS PKCS#7 for DES — don't pick None). The collapsible panel on the right shows an equivalent OpenSSL command for the current settings; sending it to the other side is the fastest way to find the divergence. openssl enc -K silently truncate or zero-pad instead, which is the number-one source of interop failures. DES/ECB/PKCS5Padding map to in this tool?Cipher.getInstance("DES/ECB/PKCS5Padding") output decrypts here with ECB + PKCS#7 and an 8-byte single-DES key. ⚠️ Java's 3DES (DESede) accepts only 24-byte keys — for the 2-key shape you must expand K1‖K2 to K1‖K2‖K1 yourself. des-ede3-cbc is 3-key 3DES + CBC, des-ede3-ecb is 3-key + ECB; des-ede-cbc is the 2-key shape. A 24-byte key selects 3-key, 16 bytes selects 2-key. "DES" defaults to ECB; OpenSSL's mode-less names des-ede3/des-ede are ECB (the CBC alias is -des3); PHP's openssl_encrypt requires an explicit algorithm name — the confusion there is that its default output is Base64 text, not raw bytes; ③ padding — old PHP mcrypt often used Zero padding, JCE uses PKCS#5/#7; ④ encoding — hex vs Base64, and case; ⑤ the CryptoJS password trap — passing a string as the "key" makes it run key derivation (MD5 + random salt, output prefixed Salted__, different every time), which is not the raw key at all — the top cause of "same code, different results every run". This tool lets you flip each one; the equivalent OpenSSL command on the right can be sent to the other side to reproduce. Security Tools
Decrypt AES online — GCM/CBC/CTR, passphrase or raw key, auto-detects OpenSSL & CryptoJS "U2FsdGVkX1" format. 100% in-browser, keys never leave the page.
Security Tools
Free online AES encryption — AES-128/192/256, GCM/CBC/CTR, passphrase (PBKDF2) or raw key. Runs 100% in your browser; nothing is uploaded.
Security Tools
Generate and verify bcrypt password hashes online — adjustable cost, $2b$/$2a$/$2y$ prefixes. 100% in your browser; your password is never uploaded.
Security Tools
Paste hex or text and get all 63 CRC-8, CRC-16 and CRC-32 variants at once. Got a checksum you cannot match? Type it in and the tool names the variant — MODBUS, CCITT-FALSE, XMODEM, KERMIT. Runs entirely in your browser.
Security Tools
Free online HMAC generator & verifier — compute or verify HMAC-SHA256/SHA1/384/512 with Text, Hex or Base64 keys and Hex/Base64/Base64URL output. 100% in your browser; your secret key never leaves the page.
Security Tools
Decode JWT tokens online with our free JWT decoder. Instantly inspect header, payload, signature, expiration, algorithm, and claims. 100% browser-based — your token never leaves your device. No signup, no tracking.