How HanOpen works

The path a file takes

1. You choose a file on a tool page or drop one on it. The browser hands the page a local file and the page reads its bytes into memory. 2. Those bytes move to a background worker so the screen stays responsive. The engine lives in that worker. 3. The worker parses the document. An HWP 5.0 file is a compound file container whose record streams must be decompressed and decoded; an HWPX file is a ZIP package whose XML is read without a browser DOM. Both routes end in one document model. 4. A writer turns that model into the format you asked for and counts what it managed to write. 5. The result comes back as a file your browser saves through its normal download dialog, and the worker shuts down to release the memory.

At no point in that list does your document become a network request.

Check it yourself

Open your browser's developer tools and select the Network tab while on a tool page. Reloading the page shows requests for HTML, styles, fonts and program files, along with Google Analytics requests.

Select and convert a file, then inspect the addresses and payloads of any new requests. The site may download additional code for conversion or previewing. Analytics can report the conversion format, elapsed time and element counts, but selected filenames and document contents are not included. Reading the document and creating the output take place within the browser.

Conversion summaries and access logs

A conversion summary counts the paragraphs, tables, images and notes detected in a document and recorded in the output. The full summary is produced in your browser to help you check the result. For document conversions, Google Analytics receives table, image and note counts together with the output format, elapsed time and success or failure counts. It does not receive the document text or filename.

These measurement requests and the web server and Cloudflare access records are separate from the document being converted. Analytics preferences control cookie use, and declining still permits cookieless measurement signals. The privacy policy explains these choices, the information involved and how inquiry emails are handled.

• Privacy policy

Browser requirements and verification

Conversion requires JavaScript and background workers; page previews also use WebAssembly. No separate program or extension is required. An organisation’s security settings can prevent these browser features from running.

Conversion, viewing and utility flows have been checked with Chromium, Firefox and WebKit engines on Windows. These checks do not establish support on every operating system or on actual Safari and iPhone devices. Large documents also depend on available device memory, so check a representative file before relying on a result.

How large a file can be

The parser needs the whole file in memory at once, and peak usage during a conversion runs to several times the size of the file. Hence the caps: 200 MB normally, and 100 MB when the browser reports a device with little memory. Everyday HWP documents are a few megabytes, so the cap mainly matters for forms full of scanned images. A file over the limit is refused before it is read.

Speed is a separate axis. What makes a page preview slow is the number of drawing objects, not the megabytes.

Protected documents

Before a conversion starts, the engine reads the file header. If the document is a distribution document, if it is password protected, or if it carries certificate based DRM, the work stops there and the page says which of the three it found. HanOpen does not decrypt those files and never asks you for a password. Ask whoever produced the document for a copy saved without the restriction.

Source code

HanOpen’s source repository is private. Each tool page describes the features provided and their limits. You can inspect network requests using the steps above to check whether a document is uploaded.