The distinction that matters
A browser-side tool reads the file with the File API and never issues a network request containing its bytes. A server-side tool posts the file to a backend, converts it there, and streams a result back. Both look identical: a drop zone, a spinner, a download button. Only one of them means a stranger now holds a copy of your document.
Marketing language does not settle it. "Secure", "encrypted", and "files deleted after one hour" all describe server-side processing — they are promises about what happens to your copy, not statements that no copy was made. The phrase to look for is that processing happens in your browser, and even that deserves a check.
How to check in about thirty seconds
- Open your browser's developer tools (F12) and select the Network tab.
- Clear the log, then drop your file into the tool.
- Sort by size. A browser-side tool shows no request whose payload approaches your file's size. A server-side tool shows one obvious
POSTof roughly that many kilobytes. - Optional but decisive: turn off your network connection and try again. Genuine browser-side processing still works offline once the page is loaded.
The offline test is the one worth remembering. It cannot be faked by wording on a landing page.
What travels with a document besides its text
Office and PDF files carry metadata that people routinely forget: author and last-modified-by names, the organisation registered in the authoring software, file paths from the machine that saved it, revision history, and in some formats the full tracked-change record and reviewer comments. Photographs pasted into a document may retain EXIF data including capture time and GPS coordinates. A converted PDF often keeps a subset of this.
Content that is visually hidden is still content. White text on a white background, rows hidden in a spreadsheet, cropped areas of an image where the original pixels remain, and text underneath a black redaction rectangle are all recoverable by anyone who opens the file with the right tool. Redaction means removing the characters, not covering them.
Documents that should not go to a third-party service
Regardless of any deletion promise, some material should never be handed to an unaudited converter:
- Identity documents, passport and national-ID scans, and anything containing a national identification number.
- Medical records, and any document naming a patient alongside a condition.
- Unsigned contracts, term sheets, and anything under a confidentiality agreement — uploading it may itself be the breach.
- Employee or customer data, payroll files, and internal salary information.
- Credentials, private keys, recovery codes, and configuration files containing them.
- Material covered by legal privilege or an active investigation.
For these, the safe options are the original application, an offline tool, or a browser-side tool you have verified with the network check above.
Questions worth asking of any tool you keep using
Who operates it? A site with no identifiable operator and no contact address has nobody to hold to its promises. Where does processing happen, and can that claim be tested? What is retained, for how long, and is that stated as a number rather than an adjective? Which sub-processors are involved — a converter running on someone else's cloud has a longer chain than the front page suggests. And what does the tool do when it cannot complete a job: a clear error is a much better sign than a plausible-looking output.
Advertising and analytics deserve one specific check. Ad and analytics scripts do not receive your file, but they do receive the URL, referrer, and approximate location of the visit. On a site whose URLs describe what you were doing, that alone can be sensitive.
A workflow that stays safe
Work on a copy, never the only version you have. Strip metadata before sharing: most office suites have an "inspect document" or "remove personal information" step, and exporting through a print-to-PDF path drops most authoring metadata as a side effect. Flatten anything you redacted and verify by selecting text in the output. Rename the file to something neutral, because file names leak project code names and client names surprisingly often. Then check the result in a different viewer before you send it.
How Document Forge answers these questions
HWPX, text, Markdown, and HTML are parsed inside the page; no request carries their contents, and the offline test above passes. HTML is sanitised and rendered inside a sandboxed frame so a hostile file cannot execute script. Existing PDFs are handed to your browser's own viewer rather than re-encoded.
Two paths involve a server and both are explicit. Legacy binary .hwp conversion requires an operator-configured converter; it is disabled by default and returns a clear error rather than a fake result. The optional server writing model sends text only after you tick a per-request consent box. Neither path is enabled implicitly, and advertising does not load until you allow optional cookies. The privacy notice states the boundary, and the about page names the operator.