Note: This approximates Jasypt PBEWithMD5AndDES. For exact compatibility, test against your Java application.
Jasypt is how Spring Boot projects keep secrets in configuration files: properties are stored as ENC(...) values and a single master password — jasypt.encryptor.password — decrypts them at startup. This tool implements the PBEWithMD5AndDES construction those ENC() values historically used, so you can see exactly what is inside one.
What is inside an ENC() value
The Base64 string wrapped by ENC() decodes to an 8-byte random salt followed by the DES-CBC ciphertext. The salt and your password are hashed with MD5 to derive both the 8-byte DES key and the 8-byte IV — that is the PBE (password-based encryption) part: no separate key or IV is stored or exchanged, everything derives from the password plus the salt that rides along with the ciphertext. Because the salt is random per encryption, encrypting the same plaintext with the same password produces a different output every time — encrypting "db-password-123" with password "masterkey" twice gave uMzTUoqi8FyoX0lWDYun9UynmyZtkDk5 and iU4W6qAowNBTgDuJFdamgJekrmlv6B+y in back-to-back runs, and both decrypt to the same value. If you expected byte-identical output, that is the salt doing its job. Sizes are predictable: 8 salt bytes plus one 8-byte block for a short secret is 16 bytes, or exactly 24 Base64 characters.
Why a real Spring Boot ENC() value may not decrypt here
This implementation is an approximation of PBEWithMD5AndDES, and the page says so in the warning banner — take that seriously. The PKCS#5 standard behind Jasypt's default iterates the MD5 derivation 1,000 times; this tool performs a single pass, and its password-to-bytes handling also differs from Java's. A ciphertext generated with the genuine 1,000-iteration derivation (AQIDBAUGBwgpYiSithhd9VcJ83Q10QaL, password "masterkey") fails to decrypt with this tool's algorithm. So treat this page as a way to understand and prototype the format — values encrypted here decrypt here, reliably — and verify against your actual Java application before depending on cross-compatibility.
There is a second, more common failure mode in the wild: algorithm mismatch. jasypt-spring-boot changed its default from PBEWithMD5AndDES to PBEWITHHMACSHA512ANDAES_256 in version 3.x. If your ENC() values came from a 3.x starter, they are AES-based with a random IV and no MD5/DES anywhere — no PBEWithMD5AndDES implementation, this one or any other, will open them. Check jasypt.encryptor.algorithm in your configuration before concluding the password is wrong. The error you get here for any of these mismatches is the same generic "Decryption failed — invalid password or corrupted data."
Whether to keep using this scheme at all
PBEWithMD5AndDES stacks two retired primitives: MD5 for key derivation and single DES for encryption, with its 56-bit key. It persists because a decade of Spring tutorials used it and because the encrypted properties are usually guarded more by the secrecy of the master password's delivery (an environment variable, a vault) than by the cipher. If you control both ends, configure Jasypt for PBEWITHHMACSHA512ANDAES_256 or move secrets to a proper secret manager; use this tool for the archaeology on what you already have.
Questions people ask
Do I paste the whole ENC(...) wrapper into the ciphertext box?
No — paste only the Base64 inside the parentheses. ENC( and ) are markers for the Spring property resolver, not part of the ciphertext, and including them will make Base64 parsing fail.
Decryption failed but I am sure the password is right. What do I check?
In order: that you stripped the ENC() wrapper; that the source system's algorithm is actually PBEWithMD5AndDES and not the newer AES-256 default from jasypt-spring-boot 3.x; and that the value was not double-encoded along the way. Also remember this tool's derivation is a single-pass approximation, so values from a stock 1,000-iteration Jasypt setup will not open here even with the correct password.
Is the master password itself stored anywhere in the output?
No. The output contains only the random salt and the ciphertext; the key and IV are re-derived from the password plus that salt at decryption time. That is also why losing the master password is unrecoverable — there is nothing in the ENC() value to recover it from.
The output format is plain Base64, so the Base64 decoder here will show you the raw salt-plus-ciphertext bytes. The bcrypt tool covers the adjacent problem — password storage — where slow, one-way hashing replaces reversible encryption.