{{ mode === 'encrypt' ? 'Protected File Ready' : 'Recovered File Ready' }}
{{ resultName || file?.name }}
{{ summaryLead }}
{{ securityPosture.label }} {{ passwordScore.label }} {{ resultMeta.algorithm }} {{ resultMeta.kdf }} {{ integrityLabel }} {{ humanSize }}
Choose one file; encryption and decryption stay in this browser until you download the result.

Drop one file here

Encrypt or decrypt locally in this browser.

{{ mode === 'encrypt' ? 'Applying cryptographic controls…' : 'Validating and decrypting payload…' }}

{{ file?.name }} loaded

Ready for {{ mode === 'encrypt' ? 'encryption' : 'decryption' }}.
Encrypt creates a protected output; decrypt expects a matching envelope or raw metadata.
Use AES-GCM for new files; choose legacy ciphers only when decrypting existing payloads.
Use a long unique passphrase; it is never sent and is needed again for decrypt.
{{ passwordScore.short }}
Download {{ mode === 'encrypt' ? 'Encrypted' : 'Decrypted' }} File
Balanced and hardened use Argon2id; compatibility switches to PBKDF2 settings.
Argon2id is memory-hard; PBKDF2 is for systems that cannot use Argon2id.
Set passes (t) and memory MB; higher values slow guesses and encryption/decryption.
t
MB
Minimum 10000; 600000+ is a stronger modern default for SHA-256.
Envelope stores salt/IV/metadata; raw outputs require you to preserve those values separately.
Choose Base64 for text-safe payloads or Hex for byte-level troubleshooting.
Leave blank to generate random; decrypt raw payloads need the exact same hex IV/nonce.
Leave blank to generate random; decrypt raw payloads need the exact same salt hex.
Optional context string; decryption fails unless the same AAD is supplied.
PKCS#7 is typical for CBC; NoPadding requires block-aligned plaintext.
Use for non-AEAD/raw compatibility flows; AES-GCM already authenticates output.
{{ hmac ? 'On' : 'Off' }}
Readonly preview; use the button to copy current envelope/raw output.
Field Value Copy
{{ row.k }} {{ row.v }}
No details available.
Step Action Copy
Operational recommendation {{ securityPosture.recommendation }}
Step {{ idx + 1 }} {{ item }} 

            

        


    



                

                

                    

                        

                            Tags: File Tools, Security
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  

    
    
Password-based file encryption turns ordinary bytes into ciphertext that should stay unreadable without the same password and the same recovery details. People reach for it when a workbook, archive, export, media file, or backup needs to move through storage or sharing channels that are not meant to expose the contents.

    
The password is only part of the story. Reliable recovery also depends on the key-derivation settings, the salt, the IV or nonce, and any extra authenticated context staying aligned. Lose one of those pieces and a valid encrypted file can become impossible to open later, even when the password itself is correct.


    

      
        Password-based file encryption flow
        Diagram showing file bytes and password entering key derivation with salt, producing encryption key material, then creating ciphertext plus IV, metadata, and integrity checks for recovery.
        
        
        File bytes
        document, archive, media

        
        Password
        human secret

        
        
        
        

        
        KDF
        Argon2id or PBKDF2
        salt changes every run

        
        salt

        
        

        
        Encryption
        AES-GCM or compatibility mode
        IV or nonce per file
        optional AAD or HMAC

        
        

        
        Output
        ciphertext
        salt
        IV or nonce
        KDF details
        integrity signal
      
    


    
Modern file protection is not just about secrecy. A damaged or modified payload should also be detected instead of decrypting into plausible garbage. That is why authenticated encryption is usually the best starting point for new work, while older compatibility formats should be chosen only when another system truly requires them.

    
The practical decision is therefore simple to state and easy to get wrong: pick settings that are strong enough to resist offline guessing, then store enough metadata that the file can still be recovered later without guesswork.

  






  

    
Technical Details:

    
Password-based file encryption has several moving parts before the first byte is transformed. A key-derivation function (KDF) stretches the password into key material, a salt makes that derivation different for each run, and an IV or nonce keeps repeated encryptions from producing the same ciphertext under the same password. After that, the ciphertext has to carry or be paired with enough recovery details for decryption to be reproduced later.

    
AES-GCM is the authenticated path offered here. It is an AEAD mode, so it combines confidentiality and integrity in one operation, uses a 128-bit authentication tag, and works with a 12-byte nonce, which matches the 96-bit IV length NIST recommends for Galois/Counter Mode. Additional authenticated data (AAD) can be attached when a file should decrypt only in the same external context, such as a case number or project string.

    
The compatibility paths are broader. AES-CBC, AES-CTR, AES-CFB, and AES-OFB are available in 128-bit, 192-bit, and 256-bit variants. DES-CBC, TripleDES-CBC, RC4, and Rabbit are also present for older environments, but they should be treated as migration or interoperability choices rather than the starting point for new protection. For integrity outside AES-GCM, the page can add a separate SHA-256 HMAC sidecar.

    
Key derivation can follow Argon2id or PBKDF2-HMAC-SHA256. The built-in balanced Argon2id profile uses 19 MB and 2 passes, which aligns with the widely cited OWASP minimum. The hardened profile moves to 64 MB and 3 passes, which matches the memory-constrained recommendation from RFC 9106. PBKDF2 remains useful for compatibility; the preset here uses 600,000 iterations with SHA-256.


    

      

        
        
          

            Format
            What is stored with the ciphertext
            Recovery implications
          

        
        
          

            Envelope (.stenc)
            Algorithm, KDF name and parameters, salt, IV or nonce, encoding, ciphertext, timestamp, original file details, and optional AAD or HMAC.
            Usually the safest recovery choice because the decrypt side does not need to guess the recipe.
          

          

            Raw text (.enc)
            IV or nonce plus ciphertext, encoded as Base64 or hex text.
            Compact, but the salt, KDF settings, algorithm, padding, and any AAD must be preserved somewhere else.
          

          

            Raw binary (.bin)
            IV or nonce plus ciphertext as binary bytes.
            The same metadata burden as raw text, just in a binary wrapper.
          

          

            OpenSSL Salted__
            An 8-byte salt header plus AES-CBC ciphertext, emitted as Base64 text or binary output.
            Useful for AES-CBC interoperability, but successful recovery still depends on matching the PBKDF2 and padding assumptions used here.
          

        
      

    


    
Decryption is easiest when the encrypted file already carries its own description. The current logic tries a JSON envelope first, then an OpenSSL-style Salted__ payload, then raw text, and finally raw binary. That order reflects how much metadata each format exposes on its own. Self-describing formats are more forgiving. Raw formats are smaller, but they fail fast when a salt, AAD value, encoding choice, or padding rule has been lost.


    

      

        
        
          

            Protection path
            Integrity behavior
            What a mismatch usually looks like
          

        
        
          

            AES-GCM
            The authentication tag is built into the encryption result.
            Wrong password, nonce, salt, AAD, or modified ciphertext causes decryption to fail.
          

          

            Non-GCM mode with HMAC
            Decryption and integrity checking are separate steps.
            The file may decrypt, but the HMAC status can still show that the payload should not be trusted.
          

          

            Non-GCM mode without HMAC
            No separate integrity proof is carried.
            A bad password or damaged data may fail outright or may produce bytes that are simply wrong.
          

        
      

    

  






  

    
Everyday Use & Decision Guide:

    
For a new encrypted file, the strongest built-in path is Encrypt file, AES-GCM, Envelope, a strong password, and one of the Argon2id presets. Leave the IV or nonce and salt blank unless you are deliberately recreating an older workflow. The page will generate fresh random values, keep the recovery details with the ciphertext, and produce an output that is easier to hand off without side notes.

    
The two Argon2id presets serve different everyday needs. Balanced is a sensible minimum for normal sharing and storage. Hardened raises the cost further for cases where the extra processing time is acceptable. PBKDF2 should usually be chosen only when another system already expects it, or when you are matching an established compatibility policy.

    
Raw and raw binary outputs belong in tightly controlled pipelines where the salt, algorithm, KDF, encoding, padding, and any AAD are already being tracked elsewhere. If you cannot guarantee that bookkeeping, do not choose raw. The OpenSSL Salted__ options are similarly narrow: they are for AES-CBC interoperability, not for starting a new long-term archive strategy.

    
AAD is worth filling in when the same file should only decrypt in a known context, such as a ticket ID, project label, or incident code. That value is not encrypted, but it is authenticated under AES-GCM, so it must match exactly when the file is opened later. The HMAC switch matters most in non-GCM workflows, because GCM already includes an authentication tag.

    
    
      
  • Evidence Ledger lists the fields that matter for audit and recovery, and it can be copied or exported as CSV or DOCX.
    • 
      
  • Payload Footprint Map turns the size impact of ciphertext, salt, nonce, AAD, auth tag, and final download bytes into a chart with image and CSV export.
    • 
      
  • Recovery Runbook gives a short settings-based checklist, which is especially useful when a chosen mode is weaker or more fragile.
    • 
      
  • JSON stores the current inputs and the generated metadata in a form that can be dropped into ticket notes or reproducibility records.
    • 
    

  






  

    
Step-by-Step Guide:

    
    
      
  1. Load the file, then choose whether you are encrypting a new payload or decrypting one you already received.
    2. 
      
  2. For new work, stay with AES-GCM and Envelope unless another system gives you a concrete reason to match a different format.
    3. 
      
  3. Enter the password and choose a KDF profile. Use Argon2id for new protection. Use PBKDF2 only when compatibility requires it.
    4. 
      
  4. Leave the IV or nonce and salt blank unless you are reproducing an existing setup. Add AAD only when the file should be tied to a known context string. Turn on HMAC for non-GCM modes when you need a separate integrity signal.
    5. 
      
  5. Run the operation and download the output. If you picked a raw format, immediately record the salt, algorithm, KDF settings, encoding, padding, and any AAD next to the file.
    6. 
      
  6. Review the summary badges, the Evidence Ledger, and the Recovery Runbook before sharing or storing the result. If the workflow needs documentation, export the ledger and JSON while the settings are still visible.
    7. 
    

  






  

    
Interpreting Results:

    
The summary badges are the fastest check after each run. Posture: Hardened usually means AES-GCM, envelope packaging, and stronger KDF settings. Posture: Balanced means the current choices are workable but not ideal. Posture: Compatibility Risk appears when older ciphers, weak password signals, lower-cost derivation, or metadata-light packaging push the result toward a harder-to-trust path.


    

      

        
        
          

            Signal
            What it reports
            Practical reading
          

        
        
          

            Security posture
            The combined effect of cipher choice, packaging, KDF cost, password strength, and integrity coverage.
            Use it as a fast quality gate before you distribute the output.
          

          

            Password strength
            A quick heuristic based on length and character variety.
            Helpful for spotting obvious weak passwords, but not a guarantee of crack time.
          

          

            Integrity label
            Built-in auth tag status for AES-GCM, HMAC sidecar status, or HMAC verification after decryption.
            If integrity fails, treat the output as untrusted even if the file appears to open.
          

          

            Algorithm, KDF, and format badges
            The exact recovery path chosen for the run.
            These are the first fields to compare when another system cannot decrypt the result.
          

          

            Human-readable size badge
            The loaded file size before the operation.
            Useful for quick sanity checks before you look at the detailed byte counts.
          

        
      

    


    
The Evidence Ledger is the authoritative record on the page. It reports the mode, format, algorithm label, KDF label and parameters, IV or nonce, salt, AAD length, auth-tag length where applicable, plaintext and ciphertext byte counts, download size, timestamps, and source type during decrypt operations. If you are debugging a failure, this table is more important than the output preview.

    
The Payload Footprint Map answers a different question: why did the finished file grow or shrink? It splits the result into plaintext, ciphertext, download bytes, nonce, salt, AAD, and auth-tag segments when those values exist. That is useful when comparing envelope against raw output, or when explaining why authenticated formats carry more bytes than the source file alone.

    
The Recovery Runbook is a plain-language checklist derived from the current settings. The JSON tab keeps the same run in a structured form. Both are worth saving when a protected file is headed into a handoff, ticket, or long-term retention process.

  






  

    
Worked Examples:


    
Sending a finance workbook to a colleague with the safest built-in path

    
Choose Encrypt file, keep the mode on AES-GCM (256-bit), use Envelope, pick the balanced or hardened Argon2id preset, and leave salt and nonce generation to the page. The result is a .stenc file that already contains the metadata needed for recovery, plus an Evidence Ledger you can export for your records.


    
Matching an AES-CBC compatibility workflow

    
If another environment expects an OpenSSL-style wrapper, choose an AES-CBC variant and one of the OpenSSL Salted__ outputs. In this path, the important follow-up is not just the password. The other side also needs the same PBKDF2 iteration assumption and the same padding choice. If you do not control both ends of that workflow, envelope output is safer.


    
Recovering a raw payload that arrived with separate notes

    
Suppose you receive Base64 ciphertext where the sender documented the salt, algorithm, and password in a ticket. To decrypt it, load the payload, select the matching algorithm and encoding, enter the salt in hex, and set any padding or AAD details exactly as recorded. Raw formats are workable only when that side metadata is complete and accurate.


    
Troubleshooting a decrypt failure

    
If you see a message about the wrong password, salt, IV, AAD, algorithm, or corrupted data, start with the format. Envelope files carry most of the recipe automatically, so the password is the first thing to verify. Raw outputs are different: compare the salt, padding, encoding, and AAD value before trying another password. For AES-GCM, even a single-byte change in AAD or ciphertext will stop decryption.

  






  

    
FAQ:

    

      Are file contents sent to a server?
      
The encryption and decryption path runs in the browser session. The selected file is read locally, and the result is emitted as a browser download rather than being processed by a dedicated backend for this tool.

    

    

      Which settings should I use for a new encrypted file?
      
Use AES-GCM, Envelope, a strong password, and one of the Argon2id presets unless another system gives you a specific compatibility requirement.

    

    

      Why did decryption fail even though the password seems right?
      
With raw formats, the password is only one part of the recovery recipe. The salt, IV or nonce, algorithm, encoding, padding, and any AAD must also match. With AES-GCM, any change in the authenticated data or ciphertext will also stop decryption.

    

    

      When is AAD worth using?
      
Use it when the file should be bound to a specific external label, such as a case ID, project code, or handoff marker. That value is not encrypted, but it must match exactly at decrypt time.

    

    

      Can this open every OpenSSL-encrypted file?
      
No. The OpenSSL path here is aimed at AES-CBC workflows that match the PBKDF2-based behavior used by this page. Older or differently configured openssl enc defaults may not line up.

    

    

      What are the main limits?
      
The whole file is buffered in browser memory, raw formats are easy to strand if metadata is lost, and AES-GCM requires a secure browser context such as HTTPS or localhost.

    

  






  

    
Glossary:

    

      
AEAD

      
Authenticated encryption with associated data. It protects secrecy and integrity together.


      
AAD

      
Additional authenticated data. It is checked for integrity but is not encrypted.


      
Argon2id

      
A modern password-based key-derivation function designed to make large-scale guessing attacks more expensive.


      
PBKDF2

      
An older password-based key-derivation method that remains common in compatibility-driven workflows.


      
Salt

      
Random input added to the password before key derivation so the same password does not always produce the same key material.


      
IV or nonce

      
A per-encryption value that keeps repeated runs from producing identical ciphertext under the same key.


      
HMAC sidecar

      
A separate SHA-256 integrity value attached to non-GCM workflows.


      
Salted__

      
A common OpenSSL header that prefixes a salted AES-CBC payload for compatibility-oriented exchange.

    

  






  
References: