They have to give you your data. Nobody said it had to arrive readable.

What happens, in order, from asking to keeping

One pass through the whole thing, from asking a service for your data to clearing it away again. Each step says what happens and why it works that way.

1. You ask them for it

   Every service has to hand over what it holds on you, and every one of them has buried the button somewhere different. The guides walk each request, screen by screen, and say what the wait usually is.

   Muletto is not involved. You are asking them directly, with your own account, and the archive arrives at your machine.

2. You open it here

   The zip's index is read from the end of the file, and entries are inflated one at a time with DecompressionStream over File.slice(). The archive is never held whole, so a 50 GB Takeout behaves like a small one. Archives past 2 GB arrive in a different format again, and that is read here too.

   Nothing is sent anywhere, and the page is served with a Content-Security-Policy whose connect-src lets the browser refuse it on our behalf. Turn off your wifi and every step below still runs.

3. It is read into one library

   Photographs, messages, location history, searches, watch history, payments and account tables, out of whatever shape each service chose - Snapchat's JSON, Meta's per-thread files, Google's per-product folders, Apple's and Samsung's CSVs - merged onto one timeline by the timestamps they already carry.

   Two services that logged the same afternoon end up next to each other, which you cannot see while they sit in separate folders.

4. Small copies are made, once

   Each picture is shrunk to a 320px copy and written to your browser's own storage, on disk. Videos give up their first frame the same way.

   A wall of three thousand photographs cannot open the originals every time you scroll - that is megabytes each. The copies are made once, in background threads so the page stays alive, and are still there next visit and when the same photograph turns up inside next year's export.

5. Duplicates are found by content

   Every file is keyed by a SHA-256 of its bytes. The archive's own checksum and length are a free first pass that only suggests a match; nothing is treated as the same photograph until the hash agrees. Near-copies are caught separately with a perceptual hash, with the flat images held back because a blank screenshot has no fingerprint worth comparing.

   The copies wasting your disk are in four different archives under four filenames with four dates. Only content finds those.

6. Dates and places are put back

   Recovered from the sidecar JSON that Google and Meta ship beside each file, or from the container for video, then written into the JPEG as EXIF DateTimeOriginal and a GPS block - rebuilt whole rather than spliced, because inserting a tag shifts every offset after it.

   A half-correct EXIF loses the date and moves the location, which is worse than leaving it alone.

7. You sort it by saying what you want

   Describe the outcome - keep the people, drop the screenshots, put the rest somewhere separate - and a model turns your sentence into rules. The rules then run here, on your own machine. Each is shown with a count and six of the pictures it caught before a single file moves.

   Only your sentence is sent. No picture is involved in writing the rules, and a mistake is something you see in a preview rather than find afterwards.

8. You can have the pictures described, if you want

   Optional, and off unless you turn it on. Each picture is sent to the AI service you pick - your own key straight from your browser, or a model running on your own machine, which sends nothing anywhere - and the sentence it writes goes into the photo file itself, so searching for beach or birthday cake finds it afterwards in any photo app.

   This is the one step where a picture of yours leaves the device, so it is the one worth deciding about deliberately. It is also the only part that costs anything. Everything above and below it happens here either way.

9. You write it out and keep it

   Straight to a folder through the File System Access API where the browser has it, or one streamed archive where it does not - compressed as it is written, so only the index is held. Descriptions go in as XMP dc:description, which Lightroom, digiKam, Immich, Bridge and Apple Photos all read.

   Ordinary folders and ordinary files. Move them to a NAS or a drive in a drawer and they stay sorted and searchable with nothing of ours involved.

10. You forget this ever happened

    We hold nothing to delete - there is no account, no server and no copy of your data anywhere but your own machine. What is left after a session is a small pile of working files in your own browser: the comparisons, the repaired dates and the little thumbnail copies. Harmless, and yours.

    One button clears them, after saying what goes and offering to save the work to a file first. Take that option and your exported folders are all that remains; take the button and there is no trace left of any of this - not with us, because there never was any, and not on your machine either.

Two honest limits. Writing a date back needs JPEG - other formats are copied untouched and reported, not silently skipped. And folder writing needs showDirectoryPicker, which today means Chrome or Edge; Safari and Firefox get one streamed archive instead.

Open an export  /  What is stored, and where  /  What the AI part costs