Skip to content
StartPrivate
Menu
Language: EN

How to check that your files stay on your device

You do not have to take our word for it. Your browser can show you every request a page makes, and it takes about two minutes to look.

Open your browser's developer tools, switch to the Network panel, clear it, then choose and process a file: the list should show no new request that carries your file, and nothing that goes to another website. The only requests you will see come from the page loading, from helpers you asked for (models and WebAssembly files from this site) and from the Cloudflare analytics beacon.

Why check at all

Every page on this site says that files are processed in your browser and not uploaded. That is a claim, and claims about privacy are cheap. The site's source code is not published, so instead of asking you to read it, this page shows you how to watch what the page actually does. Browsers record every network request a page makes, and they let anyone see that record.

The check in Chrome or Edge

  1. Open the tool page you want to test, for example the photo metadata remover.
  2. Open the developer tools with Ctrl+Shift+I on Windows and Linux or Cmd+Option+I on a Mac (or F12), and click the Network tab.
  3. Tick Preserve log so the list is not cleared if the page changes, then click the clear button (a circle with a line through it) to empty the list.
  4. Choose a file in the tool and let it finish. Press any button the tool needs, such as Start or Export, and download the result.
  5. Look at the list. In the filter box, type method:POST to show only requests that send data, then -domain:startprivate.com to show only requests to other websites. Neither filter should show anything that happened while your file was being processed.

The check in Firefox

  1. Open the tool page.
  2. Press Ctrl+Shift+E on Windows and Linux or Cmd+Option+E on a Mac to open the Network Monitor directly.
  3. In the panel's settings menu (the gear icon), turn on Persist Logs, then click the trash-can icon to clear the list.
  4. Choose and process a file, then download the result.
  5. Read the list. The filter box accepts the same kind of filters, for example method:POST, and you can click any row to see where it went and what it carried.

The check in Safari on a Mac

  1. Choose Safari → Settings, open Advanced, and tick Show features for web developers. A Develop menu appears.
  2. Open the tool page, then choose Develop → Show Web Inspector (Option-Command-I) and click the Network tab.
  3. Clear the list with the trash-can button.
  4. Choose and process a file, and download the result.
  5. Look through the new rows, if any, and click one to see its address and method.

On an iPhone or iPad, Safari has no Network panel of its own. You can turn on Web Inspector in the phone's Safari settings under Advanced, connect the phone to a Mac with a cable, and inspect the phone's tab from the Mac's Develop menu. Chrome on Android can be inspected the same way from desktop Chrome at chrome://inspect.

What you will see, and what it means

When the page loads: the page itself, one stylesheet, a few script files under /assets/, sometimes a small language file, icons and the app manifest. All come from startprivate.com. You will also see the analytics script from static.cloudflareinsights.com.

When you press a button that needs a helper: a batch of GET requests to startprivate.com for program files and models, for example under /v/ and /assets/. That is the face finder (about 1 MB), the text reader, the Content Credentials reader (about 8.6 MB), the Office library or the password word lists being downloaded. They are files coming to you, not your file going out. Click one and you will see a GET request with an empty request body.

While your file is chosen and processed: nothing new that leaves your device. You may see entries whose address starts with blob: or data:. Those are addresses inside your own browser, used for previews and downloads; they never reach the network.

The analytics beacon: Cloudflare Web Analytics sends a small report when the page loads and again when the page is hidden or closed, so switching to another tab can add a row. Depending on how the site is served, it goes to /cdn-cgi/rum on this site or to cloudflareinsights.com. Click it and open the payload: it holds page timing figures and the page address, not file contents. If you block it with a content blocker, the tools work exactly the same.

One deliberate exception: on the password strength page, ticking Check known data breaches sends a GET request to api.pwnedpasswords.com with 5 characters of a hash. It is off by default, and no other page is allowed to connect anywhere except this site and the analytics address.

A second line of defense: the security policy

Each page is sent with a Content-Security-Policy header. Among other things, it tells the browser that the page may only connect to this site and to Cloudflare's analytics address, and may only load scripts from this site and the analytics script. If any code on the page tried to send data elsewhere, the browser itself would block it and log an error. You can read the policy in the Network panel: click the first row (the page), then look under Response Headers for content-security-policy. On the password strength page you will see one extra address in it, the breach list.

Scripts and styles in each page also carry Subresource Integrity hashes, so the browser refuses to run a file that does not match the version the page expects.

How each kind of tool works

Photos (JPEG, PNG, WebP, HEIC). Metadata is removed at the byte level. The tool walks through the file's segments, chunks or boxes, drops the ones that hold EXIF, GPS, XMP, IPTC, maker notes, Content Credentials, comments and embedded thumbnails, and copies the image data across unchanged. The picture is never decoded or re-encoded, so it is pixel-for-pixel identical. The orientation tag and the color profile are kept so the photo still displays correctly. The profile stays as it is, short texts included (a description, a copyright line, sometimes the name of a device or of whoever built the profile): the result names it among what is left, and the EXIF viewer prints those texts. In Location only mode the EXIF block is edited where it stands, and only if the tool can read all of it: entries on a fixed list (dates, camera, settings, serial numbers, owner and author names) stay when they hold what such an entry should, every other entry is deleted, as is a listed entry written in another type or count than the list expects or a kept number that spells three letters of a name, and a block that cannot be read through is taken out entirely. That check on numbers concerns only numeric fields, the EXIF numbers this mode keeps and the numbers inside a colour profile (kept in both modes); cameras and phones do not write names there, only a file built on purpose would. It catches Latin, Greek and Cyrillic letters written as plain bytes, UTF-8 or 16-bit characters, accents written as separate marks included; an accented letter stored as a single byte, and other scripts, Chinese among them, cannot be told from numbers. In a color profile, the profile's size and a curve's number of points are not read as letters when they agree with the profile's structure and stay within what real profiles use (1 MB, 64 tags, 4,096 curve points); a profile outside that is listed as holding data a standard profile does not carry. Text fields such as the author or the copyright are a different matter, covered under Camera and names in Location only mode below. Data a JPEG keeps behind its main picture, such as an Ultra HDR gain map or a motion-photo video, is always dropped. Files the tool cannot walk from end to end are refused outright, as are kinds it does not cover: arithmetic-coded and hierarchical JPEG, HEIC image sequences, animated AVIF, and HEIC with unfamiliar boxes.

Video (MP4, MOV). Of the tracks, only video and audio are kept. Other tracks (GPS and sensor telemetry, timecode, camera-specific data, and subtitle tracks unless you choose to keep them) are filled with zeros and marked as free space, metadata boxes such as udta, meta and uuid are emptied, and creation and modification times are set to zero. One uuid box stays: Google's spherical video box in the track of a 360° video, which holds the projection and the name of the stitching program and which players need to show the video in 360°; it is listed as staying. Of the codec settings of the kept tracks, one field is emptied where a picture track is coded as H.264, H.265 or ProRes: the place in its description where an encoder writes its own name (a GoPro file says "GoPro AVC encoder" there), unless that place holds only the name of the coding format. Other codings keep that field. The rest is not edited and can still name the encoder, and the result lists each such name with its text. File length stays the same, picture and sound are not re-encoded, and the output is assembled from slices of your original plus small patches, so multi-gigabyte files work without being loaded into memory.

Office files (DOCX, XLSX, PPTX). These are zip archives of XML files, unpacked in a background worker and handled in two separate steps. The cleaner goes first. It removes author and company properties, comments and their authors, custom properties, hidden text, editing session IDs, co-authoring records, add-in tags, mail-merge and web-publishing settings and sensitivity-label data, and handles tracked changes by accepting them or by hiding who made them (your choice). Folder paths are shortened to the file name wherever a value is certain to be the location of a file: the target of a link, a picture description consisting of a path alone, the file a Word field is told to fetch (not the other text of a field code), and the spot in an Excel formula that names another workbook (not text typed between quotes). A path found anywhere else is left as written and listed in the result. One case escapes both: a location that a formula assembles from separate pieces of text is not recognizable as a path, and only a piece that looks like one by itself is listed. Some things are kept on purpose: digital signatures, fields in the text that display the author or the file name, data connections, add-in data, e-mail addresses behind links and links to private network addresses. The second step is an independent check of the finished file. It shares no lists with the cleaner, and it compares the output, part by part and attribute by attribute, with the published format definitions (the schema data that ships with Microsoft's Open XML SDK). A part, element or attribute counts as checked only when the definitions know it and it is found clean. Whatever else is there, including the items kept on purpose and any part or markup the tool does not recognize, is listed at the top of the result with the name of the part that holds it, in place of a statement that the file is clean. As a last step, names, initials and account ids read from the original file are searched for in every part of the cleaned one, and any that turn up are listed too. If a name recorded in the file's properties (the author, the last person to save it, a comment's author and so on) also appears in the document's own text, it is listed among the warnings, whether that text is shown or hidden; whether the name stays is yours to check and decide. A few cases produce a quiet note in place of a warning: text in the content that reads like a folder path, an internal address or an account (see the limits below); and a recorded name that could not be searched for, either because it is only one or two letters or digits long or because the part of the original holding it could not be read. A part counts as not read when a conforming XML reader refuses it, even if names were found in it; so does one with a document type declaration, or one whose declared encoding is none of UTF-8, UTF-16, windows-1252, ISO-8859-1 and US-ASCII. A handful of default words such as "User" are not searched for at all; the Limits section below names them. Parts are unpacked one at a time, within fixed limits (64 MB for one part or picture, 256 MB for all the text parts together, 512 MB for everything in the package, pictures and unopened parts included, one million pieces of XML in a part, counting each element, comment and stretch of text between tags, 512 levels of nesting, 2,048 in a part read in one pass, 2,000 attributes on one element and 10,000 entries in the package), so a file built to exhaust memory is refused, not processed. A before-and-after table lists what changed. Embedded photos (JPEG, PNG, WebP, HEIC) go through the photo cleaner; any other embedded picture, media file or object is not opened and is reported as left in the file.

Content Credentials viewer. The page first checks locally whether a file contains C2PA data at all. Only then does it load the reader, configured not to fetch remote manifests, revocation status or trust lists. That is why it reports whether a signature is intact, not whether the signer is trusted.

Redaction. The editor draws a working copy on a canvas, capped at roughly 2,048 pixels per side, and keeps boxes in the original's coordinates. Export repaints the full-size image with the covers and encodes a new file in a background worker, which is why no metadata comes along. If the browser cannot encode the full size, it retries at 4,096 pixels. The face finder is the YuNet model running on TensorFlow.js Web; the text finder is the Tesseract OCR engine plus pattern rules and the ZXing barcode reader.

Passwords and passphrases. All randomness comes from the browser's crypto.getRandomValues, with rejection sampling so every character or word is equally likely. Nothing generated is stored or sent.

File hashes. Files are read in 8 MiB slices in a background worker and fed to the hash-wasm implementations of SHA-2, SHA-1 and MD5.

Text encryption. AES-256-GCM from the browser's Web Crypto API, with keys derived from passwords by Argon2id (64 MiB, 3 passes) from hash-wasm.

Password strength. zxcvbn-ts scores the password on the page; the breach check described above is the only part that can make a request.

Limits

These tools remove what they recognize and list what they keep. A result that lists nothing therefore means "nothing this tool checks for was found", never "this file says nothing about you". Here is what the tools do not do.

How the site is tested

Before a version is published, it goes through:

What your browser reveals on its own

This page is about files. Your browser also tells every website some things about you just by connecting, such as your IP address, approximate location, language and screen size. To see what your browser reveals to websites, you can run a separate check.

Sources

Checked 2026-10-11.

Last updated: