Documents in. PDFs out. Nothing leaves your machine.

No. There is no server on the other end. The page is served with a Content-Security-Policy that sets connect-src to none, which means the browser itself refuses to let it open a network connection at all. Open your developer tools, watch the network panel while you convert something, and you will see nothing leave.

Eight picture formats (JPG, PNG, HEIC, WEBP, AVIF, GIF, BMP and SVG) and four text ones: plain text, Markdown, HTML and CSV. PDFs can be dropped in as well, but they are merged rather than converted, since they are already the output format. A .docx file converts too: paragraphs, headings, lists, tables and images carry across, headers and footers repeat on every page, and footnotes land in a numbered notes section at the end of the document. An .xlsx file converts as well: every sheet, in order, with number formatting (dates, currency, percentages) and merged cells kept. An .epub converts too: every chapter in order, with a generated table of contents and any cover image up front. The older .doc and .xls formats, and a DRM-protected EPUB, are not yet offered.

Several libraries, and none of them is an analytics or advertising script. pdfmake builds the document, pdf-lib merges PDFs that arrived as PDFs, markdown-it and DOMPurify read Markdown and HTML, Papa Parse reads CSV, bidi-shaper handles Arabic and Hebrew, and libheif decodes iPhone photographs. Every one of them runs in your tab under the same policy that forbids this page a network connection, so none of them can send anything anywhere whatever it was written to do. libheif is LGPL-3.0 and ships unmodified with its licence; the rest are MIT.

It is split down its columns into blocks that do fit, each with its own heading row and a caption saying which columns it holds, so every cell survives. Letting the table shrink to fit instead loses the last columns without saying so, which is what most converters do. Landscape or a larger page size puts more columns in each block.

Latin, Greek and Cyrillic convert with the bundled font, so most European languages are fine, accents and all. Chinese, Japanese, Arabic and Hebrew need a font pack, and that pack is applied on the spot: the row simply converts, a few megabytes heavier the first time a script appears. Korean, Thai and Devanagari are refused outright, because no pack here draws them and blank pages are worse than a refusal.

Once the page has loaded, yes. Conversion runs in your browser, so you can switch the network off and keep converting. The one thing that needs the network is loading the page in the first place.

Only your device. Nothing is uploaded, so there is no upload cap, but the whole document is built in memory. Very large files convert more slowly and a very large batch can exhaust a tab.

Because the orientation stored in the file is read rather than ignored. A phone held sideways records the picture one way and tags it with a quarter turn, and a converter that skips the tag prints it on its side. LocalPress reads it, and measures the page against the size the picture is actually drawn at.

That row says so, with the reason, and the rest of the batch carries on. Being refused and failing halfway are different things and are shown differently, because one tells you to convert the file another way and the other tells you the file is damaged.

No. A finished PDF is held in memory until you download it and is gone when you reload the page. The list of recent conversions keeps names and dates on this device only; there is nowhere in that record for a file to go.