Skip to main content
Toollyz

Search tools

Search for a command to run...

Secure File Shredder

Overwrite the in-memory copy of a file with crypto-random bytes (DoD 3-pass, single random, zero-fill or one-fill) before downloading the shredded version. SHA-256 receipt included. 100% client-side, no upload.

What is the Secure File Shredder?

Secure File Shredder takes a file you select, overwrites its in-memory copy with crypto-random bytes (or a DoD-5220.22-M-style 3-pass pattern) and offers the shredded version as a download. We use `crypto.getRandomValues` for entropy, chunked through the typed-array in 64 KB blocks to respect the per-call API limit, and yield to the event loop between passes so the UI stays responsive on multi-megabyte files. Four patterns: single random pass (fast), DoD 3-pass (zeros → ones → random), pure zero-fill (sparse-file friendly) and pure one-fill. After shredding, we compute a SHA-256 of the resulting bytes as a receipt-style proof of the wipe. Important honest framing: browsers cannot touch files on your disk — the sandbox forbids it. This tool overwrites the IN-MEMORY COPY of the file you picked. You then move the shredded download over the original yourself. Useful for sharing a file's slot (size + filename) without leaking contents, or for confirming an upload pipeline reads bytes rather than file references. 50 MB cap.

How to use it

  1. Pick a file with the file-picker or drag-and-drop into the panel.
  2. Choose a shred pattern — DoD 3-pass (default), single random, zero-fill or one-fill.
  3. Click 'Shred' and watch the progress bar tick through each pass.
  4. Download the shredded file and (optionally) drag it over the original on your disk.

Benefits

  • Four shred patterns: DoD 5220.22-M 3-pass, single random, zero-fill, one-fill.
  • crypto.getRandomValues in 64 KB chunks for cryptographically-strong entropy that respects the per-call API ceiling.
  • Per-pass progress callback so the UI tracks each pass for big files.
  • Yields to the event loop between passes — the UI stays responsive on multi-megabyte buffers.
  • SHA-256 receipt of the shredded output as a verifiable proof-of-wipe.
  • Drag-and-drop file picker with 50 MB cap to prevent runaway memory use.
  • Honest framing in the UI: we explain what the browser sandbox can and can't do.
  • Runs 100% in your browser — files are never uploaded to a server.

Frequently asked questions

Does this actually delete my file from disk?

No — and we say so prominently in the tool. Browsers sit inside a sandbox that forbids touching files on disk. What the tool does is overwrite the IN-MEMORY copy of a file you picked and offer the shredded version for download. You can then drag the shredded version over the original yourself if you want to replace it.

What's the DoD 5220.22-M pattern?

A historical US Department of Defense standard for sanitising magnetic media: pass 1 = all zeros (0x00), pass 2 = all ones (0xFF), pass 3 = cryptographic random. Modern SSDs and flash media don't benefit from multi-pass writes (write amplification), but the 3-pass dance is still a recognisable belt-and-braces signal.

When would I actually use this?

(1) Confirming an upload pipeline copies bytes — shred a known-content file, upload, verify the backend sees random bytes. (2) Sharing a file's metadata (name + size) without the contents — say, demonstrating a workflow without exposing real customer data. (3) Personal-data sanitisation when you have to send a placeholder of a given file size.

Why is there a 50 MB cap?

Browsers allocate a Uint8Array of the file's size in memory. 50 MB is a comfortable ceiling on phones and laptops; bigger files risk OOM crashes in the browser tab. For larger jobs, use a native tool like `shred -u` on Linux.

Is the random source strong enough?

Yes — we call `crypto.getRandomValues`, which is the WebCrypto cryptographically-strong RNG. The implementation is platform-native (BoringSSL on Chrome, etc.) and seeded from the OS entropy pool.

Why chunk into 64 KB blocks?

`crypto.getRandomValues` caps at 65 536 bytes per call. We iterate the buffer in 64 KB slices and fill each independently. The same code path handles 1 KB and 50 MB inputs uniformly.

What does the SHA-256 receipt prove?

It proves the byte sequence of the shredded download — useful when you want to attest later that a particular file was written. Don't rely on it for tamper-evidence after the fact; once the file leaves your browser, its hash can change.

Will this work on flash / SSD storage?

Multi-pass overwrites are designed for magnetic media. Flash and SSD storage controllers do wear-levelling, so the original blocks may still exist physically. For SSD sanitisation use the drive's built-in Secure Erase command, not this tool.

Does the original filename stay the same?

We suggest a `<name>.shredded.<ext>` filename for the download. You can rename it anything when saving.

Does my file leave my browser?

No. The file is read with FileReader, processed in-memory, and downloaded back to you via a blob URL. Toollyz has no server that ever sees a byte of the file.

Can it shred multiple files at once?

Not yet — the current version handles one file at a time. Drag-and-drop another file when you're done with the first.

Related tools

See all developer tools