# How to check that your files stay on your device

> 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.

- **Paths that a formula puts together.** An Excel formula can assemble an address or a folder path from separate strings, for example `="D:\Team\" & B2 & "\plan.xlsx"`. Seeing that the result is a path would mean working the formula out, and the tool only reads it. A single piece that looks like a path, here `"D:\Team\"`, is still listed.
- **Names that are common default words.** If the name or company recorded in an Office file's properties is exactly one of "user", "admin", "administrator", "owner", "author", "guest", "unknown", "test" or "microsoft", in capitals or not, the property is removed like any other, but the rest of the file is not searched for that word. It turns up in the font, theme and style names of ordinary files, and nearly every find would be a false one. A recorded name, company or account of only one or two Latin letters or digits ("HP", "Jo") is not searched for either, nor is a value with no letter or digit in it or an id made of zeros alone; in those cases the result says so for the file. A name in another script, such as Chinese or Arabic, is searched for at any length. The initials Word and PowerPoint store next to a comment's author are the one exception to that note: when they are one or two letters or digits long they are not searched for and nothing is said, because the author's full name, which is searched for, stands right beside them. Initials of three characters or more are searched for like a name.
- **Names written in code.** After cleaning, the tool searches the file for each name, set of initials and account that was recorded in the original. It compares every text as it stands and again with a fixed list of spellings undone, ten in all: XML character references (`&#74;`); the `_x004A_` form Excel uses; percent-escapes (`%4A`); differences of letter case, of width and of characters that do not show; a quotation mark written twice inside a formula; an apostrophe written twice in a quoted sheet or workbook name (`'O''Brien'!A1`); `&&` for an ampersand in an Excel header or footer; `+` for a space after the `?` of a link address; `\"` and `\\` in a Word field code; and the escapes of JSON text (`\u004A`), which reference managers store in field codes. Each one applies only in the kind of place where the format uses it. Nothing else is decoded: a name kept as base64, as an internationalized domain in its `xn--` form, or spelled with the backslashes of a number format (`\J\a\n\e`) is found only where it also stands in plain form.
- **Paths and internal addresses in what the document itself says.** The text of a document, the cells of a workbook and the words on a slide are yours, and the tool does not edit them. It does point out, in a **Good to know** note under the result, text there that reads like a folder path with a drive letter, a network share, a personal folder (`~`, `/Users/…`, `/home/…`) or a variable such as `%USERPROFILE%`, like an address inside a private network (`http://intranet/…`), or like an account id. The note says what the text looks like, not that it is one. Other text shaped like a path gets no note: the path half of a web address (`/v1.0/teams`), an XPath, a line of sample code that starts with `//`, `localhost`, a placeholder host written in braces. The same values in places a reader does not see (properties, defined names, link targets, field codes) are listed as before, in the box of what is still in the file.
- **Web links judged by how they are written.** Every link to a public web page is listed, because the address behind a link is not shown on the page. A link that sits on text, a cell or a picture in one of the ordinary ways Word, Excel and PowerPoint write links is listed as a quiet note under **Good to know**. A link written any other way (in a header or a comment, on a hover action, on a merged-over or empty-looking cell, inside an equation, under a slide layout the slide does not show) is listed as a link still in the file, whether or not it can be seen, since the tool does not try to work out where such a link is shown. A link here means one the program follows when it is clicked: a hyperlink stored behind text, a cell, a shape or a picture, a HYPERLINK field in Word, and a HYPERLINK formula in Excel whose address is written out in full. A web address that is only written down, in the text, in a picture's alt text or in a link's tooltip, is treated as text, under the rules above for content and for text the file records.
- **Text that is shown but hard to see.** Office files can hide content with switches of their own: the hidden font effect, an object set to hidden, a row, column, sheet or slide that is hidden, an equation part set not to show. The tools read those switches. They do not judge what the formatting does to text that is switched on: white text on a white page, a font size of one point, a shape placed over a paragraph, an object dragged off the slide or the page. Such text is treated as ordinary content, so look for it yourself; the Office pages say where.
- **Names and alternative text of objects that are shown.** A picture, shape or control that is shown keeps its name and its alternative text as part of the file, and they are not reported as hidden content; only an object that is hidden or not drawn has them listed. A name or an alternative text that is nothing but a folder path is shortened like other paths. A path, an internal address or an account inside a longer one is reported, and so is a name recorded in the file's properties.
- **Mixes of accepted and rejected tracked changes.** When a Word document keeps its tracked changes, whoever opens it can accept or reject each change on its own. The combinations that such separate choices produce are not checked one by one; what every person typed, as they typed it, is checked.
- **What the picture shows.** The compressed picture data and the color palette are copied without being examined. A face, a number plate, a house front, words that were photographed or drawn into the picture: all of it stays. Covering such things is the job of the [redaction tool](/redact-image/).
- **The cropped-off part of a picture in an Office file.** Cropping a picture in Word, Excel or PowerPoint only hides the edges; the whole picture stays in the file, and anyone who receives it can undo the crop. The tool cleans the picture's metadata but does not touch its pixels, so the cut-off part is still there after cleaning. To remove it, select the picture in Office, choose **Compress Pictures** on the **Picture Format** tab and tick **Delete cropped areas of pictures**, or save the cropped picture as a new image file and insert that instead.
- **What a binary value in an Office file encodes.** The formats store a few values as encoded binary data: the hash and the salt of a password that protects a sheet or a document, the strokes of ink. Where such a value is well-formed binary data, of the length its kind calls for, the tool does not try to read a meaning out of it. A value in such a place that is not well-formed is checked like any other text and reported; ink is always listed part by part.
- **Camera and names in Location only mode.** That mode is defined to take out the place and leave the other facts about the shot. The camera make and model, the software and the lens fields stay, and so do the owner, artist and copyright fields. Where such a name field holds something, the result shows it among what is left. The serial numbers of the camera body and of the lens stay in this mode too, and a filled one is likewise shown among what is left, since it is identical across every picture from that device.
- **Color profiles.** A profile is kept, because removing it changes the colors, and the result lists it. Text in a profile beyond what a standard profile carries (a description, a copyright line, a device name) is listed as an item of its own and shown by the EXIF viewer; the tool does not rewrite it.
- **Folder paths in a rare spelling inside longer text.** Recognized: a value that is a path from its first character to its last, or one whole quoted argument of a field code. That means a root (a drive letter with or without a slash after it, a network share, `/`, `~`, a `file:` address in small letters, an environment variable, the old Mac `Macintosh HD:`) followed by two or more names; no file extension is needed. After a drive letter, a share, a home folder or an environment variable the two separators may be mixed (`C:\Users\Alice/Documents/a.docx`, as programs written for several systems produce it); after a bare `/` the names must be divided by the same separator. Two roots are held to more, even where the path is all the value holds. An old Mac path on a disk with a name of its own counts only when it runs down to a file name with an extension: `Work Disk:Profiles:Alice:secret.docx` is recognized and `Work Disk:Profiles:Alice:plan` is not, because labels divided by colons, such as `IT:Applications:Support`, are written the same way. And `File:` with a capital letter counts only when a slash or a drive letter follows the colon: `File:Users` is not recognized, because wiki page titles such as `File:Flag_of_Japan.svg` look like that. Inside a longer text, the common spellings are recognized: a drive letter followed by a slash (`C:\` or `C:/`), a network share (`\\server\share`), a `file:` address, `/Users`, `/home` and the other usual system folders, `~/`, environment-variable paths such as `%USERPROFILE%\Documents`, and the old Mac form `Macintosh HD:Users:…`. What may not be recognized is a path in a rarer spelling in the middle of a longer text. One example is the drive-relative form in "see C:x\Alice\notes". Another is a root with nothing after it in the middle of a sentence, such as "see ~jane/ now" or "see \\\\fs01\\ now": the account or the machine named in the root is then not picked out. Such a bare root is recognized only where it is the whole quoted argument of a field code. Every path that is recognized is either shortened or listed.
- **Encoder names in a video.** Where a track is coded as H.264, H.265 or ProRes, the encoder name field in its description is cleared (it says "GoPro AVC encoder" on GoPro clips and "Lavc61.19.101 libx264" on files exported with FFmpeg), unless its whole value is a coding format and nothing else ("H.264", "AVC Coding", "HEVC", "HEVC Coding"), which stays and is not listed. Other codings keep that field, and it is listed: some decoders read it (FFmpeg picks the pixel layout of uncompressed video by it). The other places where an encoder or a camera's software writes its name stay in a cleaned video, in every mode: the four-letter vendor codes of the track descriptions and handlers, text inside other codec settings, and the banner some encoders put at the very start of the picture or sound data, which are parts a decoder reads. Rewriting those has not been shown to be safe for playback, so they are left alone. The result lists the names it finds in the file as they are written: the first five are shown and the rest counted, at most 32 are gathered per file, and a long one is cut at 100 characters. Such a name usually says which program or camera model made the recording. The tool does not judge what the text says, though, and an encoder's banner can hold more than a name, for instance a folder path from the computer that encoded the video.
- **Previews inside a HEIC.** The preview picture a HEIC stores as an item of its own is kept, and the result lists it. A preview stored as a JPEG item with metadata of its own is cleaned. A photo that was cropped or edited on the phone can carry an older preview that still shows the picture as it was before.
- **One very long text.** Within a single element the check keeps at most 4,194,304 characters of text, about 4 million. A part that holds a longer one is still cleaned, but it is listed as not checked, never as clean. In the real files the tool is tested on, the longest text of one element has 39,540 characters.
- **Counts in unusual layouts.** In some unusual layouts, a name or another item can be counted more or fewer times than it occurs, or listed as a possible match where it does not really stand; nothing is left out because of it.
- **Files built on purpose to get past the checks.** A file crafted to slip data past these tools can carry a few forms they fail to recognize or remove: spellings, padding or encodings no Office program writes; parts that contradict each other or break the format's rules; values hidden in the numbers of a photo's Photoshop settings, which are not shown one by one; oversized metadata fields, which can slow the viewer.

## How the site is tested

Before a version is published, it goes through:

- **Unit tests** on the parsing and cleaning code, using real camera files and small synthetic samples, with a test for each known trap: JPEG orientation, WebP header flags, HEIC item locations, 64-bit video offsets, fragmented MP4, multiple GoPro data tracks, both DJI subtitle formats, Office revisions and comments, and the large-image fallback. For Office files, hand-built documents cover each construct the Office pages list; a case passes only if the identifying value is gone from the output or the result names a matching item. Another test fails if the independent check ever imports the cleaner's code.
- **Browser tests** in Chromium, Firefox and WebKit, at desktop and phone sizes. Each tool is given sample files, and the test fails if any request other than a GET, or any request to another site, happens between choosing the file and the result, or if the console reports an error or a security-policy violation.
- **Independent checks of the output** with ExifTool, ffprobe and LibreOffice: the fields a tool reports as removed are gone, files open normally, cleaned photos decode to exactly the same pixels as the originals, and cleaned videos have identical audio and video packets. Cleaned Office files must also pass Microsoft's Open XML SDK validator with no error the original did not already have.
- **Large files:** 48-megapixel photos, a 2 GB video and a batch of 50 files, in phone emulation.

## 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](https://iseeu.cc/), you can run a separate check.

## Sources

Checked 2026-10-11.

- [Chrome DevTools: Network panel](https://developer.chrome.com/docs/devtools/network): recording, Preserve log and filters.
- [Firefox Network Monitor](https://firefox-source-docs.mozilla.org/devtools-user/network_monitor/): opening it with Ctrl+Shift+E or Cmd+Opt+E.
- [Apple: Enabling features for web developers](https://developer.apple.com/documentation/safari-developer-tools/enabling-developer-features): the Show features for web developers setting.
- [Cloudflare Web Analytics: data origin and collection](https://developers.cloudflare.com/web-analytics/data-metrics/data-origin-and-collection/): where the beacon loads from and where it reports.
- [Open XML SDK on GitHub](https://github.com/dotnet/Open-XML-SDK): the published schema data the Office check compares files with.

Last updated: 2026-10-17
