How to excel aes-256 is strong — but a weak password defeats it. test yours.
- Step 1Understand what AES-256 does and doesn't protect — AES-256 protects the file's contents *if* the key is hard to obtain. The key comes from your password via PBKDF2/SHA-512. So the password — not the cipher — is what an attacker goes after. This tool audits that password.
- Step 2Open the auditor — The Excel password-tester redirects to the Password Entropy Auditor at
/security-tools/password-entropy-auditor. There's no file to upload; you score the password that will derive the encryption key. - Step 3Paste your candidate password — Type or paste into the Password field (placeholder
Type or paste a password). It's shown in plain text and never leaves your browser — test it somewhere private. - Step 4Click Run Password Auditor — zxcvbn scores the string locally and shows the Score X/4 plus the offline fast-hash crack time. This is the real-world strength of your AES-256 protection, since the key is only as strong as the password.
- Step 5Compare a weak and a strong candidate — Test
Finance1, then test a four-word passphrase. Same AES-256 encryption, wildly different crack times — that contrast is the whole lesson, and it makes the case to colleagues better than any slide. - Step 6Apply the strong password in Excel — Once you reach
Score 4 · centuries, set it via File → Info → Protect Workbook → Encrypt with Password. Now AES-256 and the password are both strong, and the chain has no weak link.
AES-256 vs the password: who actually gets attacked
The two halves of Excel's protection and where the real risk lives. The encryption is essentially unbreakable; the password is the entire attack surface.
| Component | How strong it is | Is it the attack target? |
|---|---|---|
| AES-256 cipher | 256-bit key — brute-forcing the key space is infeasible for any attacker | No. No one attacks the cipher directly |
| Key derivation (PBKDF2 / SHA-512) | Slows each password guess via many iterations, raising the cost per attempt | Indirectly — it slows the password attack, but doesn't stop a weak password falling |
| Your password | Anywhere from Score 0 (sub-second) to Score 4 · centuries | Yes. This is what attackers guess, and what determines real security |
| The derived AES key | Exactly as strong as the password that produced it | Recovered automatically the moment the password is guessed |
Same AES-256, very different security (real results)
Identical encryption, different passwords, dramatically different outcomes. Crack times are the offline fast-hash figures the auditor reports.
| Password (same AES-256 file) | Score / crack time | Effective security |
|---|---|---|
Finance1 | 1 · Weak · less than a second | Negligible — AES-256 wasted |
Summer2026! | 2 · Fair · less than a second | Negligible — looks complex, isn't |
xK9#mL2vQp | 3 · Strong · 1 second | Weak — too short to leverage the slowdown |
correcthorsebatterystaple | 4 · Excellent · 8 hours | Moderate — a known phrase caps it |
glacier-pencil-vivid-7-quartz | 4 · Excellent · centuries | Strong — AES-256 finally doing its job |
Cookbook
A guided tour through the AES-256-vs-password relationship, using real zxcvbn output. Every password below sits behind the same AES-256 encryption — only the password differs.
AES-256 with a weak password = no real security
This is the core point. The file is encrypted with AES-256, but because the password derives the key, a sub-second password crack hands over that key. The cipher's 256 bits are never tested.
Password: Finance1 Encryption: AES-256 (unchanged) Result: Score 1/4 · Weak Crack time (offline fast hash): less than a second → The attacker guesses the password, derives the key, opens the file.
Why PBKDF2 helps a little but not enough
Excel's key-derivation makes each guess slower, but it can't turn a guessable password into a strong one. A short random password leverages the slowdown only marginally — still cracked in about a second.
Password: xK9#mL2vQp (10 random chars) Key derivation: PBKDF2/SHA-512 slows each guess Result: Score 3/4 · Strong Crack time (offline fast hash): 1 second → Slowdown bought ~1 second. Length is what scales it to centuries.
Complexity theatre vs real entropy
Mixed case, a digit, and a symbol satisfy a complexity policy and feel strong, but the structure (word + year + symbol) is predictable. AES-256 can't compensate.
Password: Summer2026! Result: Score 2/4 · Fair (similar to a common password) Crack time (offline fast hash): less than a second → Passes the policy, fails reality. The cipher is irrelevant here.
When AES-256 finally matters
Give the same encryption a high-entropy passphrase and the crack time jumps to centuries. Now the password is no longer the weak link, and the AES-256 is doing exactly what it's for.
Password: glacier-pencil-vivid-7-quartz Result: Score 4/4 · Excellent Crack time (offline fast hash): centuries → Both halves strong. No weak link in the chain.
The side-by-side that convinces a team
Run two candidates back to back to show that the security difference is entirely the password, not the encryption. It's the most persuasive demo for getting colleagues to stop using word+year passwords.
Same file, same AES-256: Finance2026 → Score 1 · less than a second cedar-lantern-brisk-9-fathom → Score 4 · centuries Identical encryption, ~10^x difference in real security.
Edge cases and what actually happens
'It's AES-256, so it's secure' is half the story
Common misconceptionAES-256 secures the contents only if the key is hard to get, and the key is derived from your password. A weak password yields a weak key, which an attacker recovers by guessing — the AES-256 is never directly attacked. The cipher strength is real but moot when the password is Finance1.
PBKDF2 slows guesses but can't save a weak password
Helps, not enoughExcel's key-derivation uses many SHA-512 iterations to make each guess cost more. That meaningfully slows attacks, but a guessable password is still guessed quickly — the slowdown turns 'instant' into a slightly-less-instant for short passwords. Entropy from length, not the KDF, is what reaches centuries.
A high score with a short crack time still loses
Read the crack timeTr0ub4dor&3 scores 4 but cracks in 10 seconds, and correcthorsebatterystaple scores 4 but cracks in 8 hours. The number 4 means 'best bucket', not 'uncrackable'. For the password to actually justify the AES-256, demand a crack time of centuries.
Protect Sheet isn't encryption at all
No AES involvedExcel's Protect Sheet (the edit/read-only lock) uses a weak legacy hash and applies no encryption — its password is bypassed in seconds regardless of strength. Only Encrypt with Password uses AES-256. Don't conflate the two; this tool audits the password that derives the AES-256 key.
The auditor doesn't test against Excel's actual cipher
By designIt scores the password string with zxcvbn; it doesn't simulate Excel's PBKDF2/AES pipeline. That's fine, because the password's entropy is what governs the whole scheme. The crack time shown (10 billion guesses/sec, offline) is a sound proxy for the real attack on the derived key.
Bigger key (AES-128 vs AES-256) doesn't change the password problem
Not the bottleneckWhether Excel used AES-128 or AES-256, the attacker still goes after the password, not the key space — both key sizes are infeasible to brute-force directly. Upgrading the cipher does nothing for a weak password. Fixing the password fixes the actual vulnerability.
l33t substitutions don't add entropy
Low impactSwapping letters for symbols (P@ssw0rd) is the first transform attack tooling applies, so zxcvbn discounts it to near-zero — P@ssw0rd scores 0. The AES-256 can't recover the entropy the substitution failed to add. Use unique words and length instead.
Older .xls files use far weaker encryption than .xlsx
Format mattersThe legacy .xls (Excel 97–2003) format used RC4 with a 40-bit key by default — weak regardless of password. Modern .xlsx is the one with AES-256. If you're protecting something sensitive, save as .xlsx first, then apply a strong audited password; otherwise the format itself is the weak link.
The auditor never transmits the password it scores
Expectedzxcvbn runs in your browser, so the candidate that will derive your AES key is evaluated locally and sent nowhere. This is deliberate — testing the real password must not create the very exposure encryption is meant to prevent.
A strong password can't undo a leaked file
Prevention onlyAuditing improves a password going forward; it can't retroactively protect a copy already in the wild with a weak password. If a weakly-protected file leaked, assume it's compromised, re-protect with a strong audited password, and don't reuse the old one anywhere.
Frequently asked questions
If Excel uses AES-256, why does the password matter at all?
Because AES-256 needs a key, and Excel derives that key from your password (via PBKDF2 with SHA-512). Attackers don't brute-force the 256-bit key — they guess the password, and a correct guess hands them the key. So the file is only as secure as the password. A weak password makes the AES-256 essentially decorative.
What is PBKDF2 and does it actually help?
PBKDF2 is a key-stretching function: it runs the password through many iterations of a hash (SHA-512 in modern Excel) so that each guess an attacker makes is computationally expensive. It genuinely slows attacks, but it can't fix a guessable password — it turns an instant crack into a slightly slower one. Real safety comes from password entropy on top of the KDF.
Which matters more: AES-256 or password strength?
Password strength, in practice. AES-256 is already effectively unbreakable, so it's never the weak link. The password almost always is — it's the part attackers target and the part that ranges from sub-second to centuries. Pour your effort into the password; the cipher is already taken care of by Excel.
Does this tool test my password against Excel's real encryption?
No — it scores the password string with zxcvbn rather than simulating Excel's PBKDF2/AES pipeline. That's the right approach: since the password's entropy governs the entire scheme, scoring the string tells you how strong the derived key will be. The offline fast-hash crack time is a sound proxy for the real attack.
Is Excel's AES-256 implementation trustworthy?
The modern .xlsx encryption (AES-256 in CBC mode with a PBKDF2/SHA-512 key derivation) is a sound, standard design, and the cipher has no practical break. The historical weaknesses in Excel security were in the old .xls RC4 scheme and in the non-encrypting Protect Sheet feature — not in .xlsx AES-256. Keep using .xlsx and focus on the password.
What's the difference between Protect Sheet and Encrypt with Password?
Protect Sheet locks editing/visibility using a weak legacy hash and no encryption — it's bypassed in seconds and its password strength is irrelevant. Encrypt with Password (File → Info → Protect Workbook → Encrypt with Password) actually encrypts the file with AES-256. Only the latter depends on password entropy, and it's the one this tool is for.
Would using AES-128 instead of AES-256 make my file less secure?
Not in any way an attacker can exploit — both key sizes are infeasible to brute-force directly, so the cipher choice isn't the bottleneck. The attacker goes after the password regardless. Whether Excel used 128 or 256 bits, a weak password is cracked and a strong one isn't; the password is what to optimise.
Why does a complex-looking password still score low?
Because complexity rules reward structure that attackers expect. Summer2026! has upper, lower, digit, and symbol, yet scores 2 with a sub-second crack time because season+year+symbol is a known pattern. zxcvbn measures guessability, not character classes — and AES-256 can't compensate for a guessable password.
Is the password sent anywhere when I test it here?
No. zxcvbn runs entirely client-side in your browser. The password you type — the one that will derive your AES-256 key — is scored locally and never transmitted. That's essential: testing the real password must not create the exposure that encryption exists to prevent.
If AES-256 is unbreakable, can I recover a file if I forget the password?
No, and that's the trade-off. A strong password produces an AES key no one can feasibly brute-force, including you. JAD can't recover it and neither can any cracking tool against a Score 4 · centuries password. Store the password in a password manager so 'unbreakable' doesn't become 'unrecoverable' for you too.
Does saving as a different format change the encryption strength?
Yes, significantly for legacy formats. The old .xls (97–2003) format defaults to weak RC4/40-bit encryption that's poor regardless of password. The modern .xlsx format gives you AES-256. Always save sensitive files as .xlsx before encrypting, then apply a strong audited password — otherwise the file format itself is the weak link.
Beyond a strong password, what else hardens a shared Excel file?
Strip what the encryption doesn't hide once decrypted: remove hidden sheets, comments, macros, and metadata before sharing. Run the hidden-sheet destroyer, the comment and note purger, and the VBA macro stripper, and consider hashing the file with the SHA-256 fingerprinter for tamper-evidence.
Privacy first
Every JAD Excel tool runs entirely in your browser using SheetJS and ExcelJS. Your spreadsheets, formulas, and data never leave your device — verified by zero outbound network requests during processing.