Loading the tool and processing your file are different network activities
Opening a page downloads site resources such as HTML, JavaScript, CSS and images. Word, PowerPoint and Excel to PDF also download LibreOffice WebAssembly and data chunks as static engine resources.
The current core processing flow does not POST the contents of your selected image, PDF or Office document to a conversion server. The browser reads and processes that file data locally.
- Site scripts and WebAssembly resources can be downloaded.
- There is no separate file-upload API used by the core conversion flow.
- If advertising or analytics scripts are present, their network requests are separate from file processing.
Image tools use the browser Canvas pipeline
After you choose an image, the browser checks the file signature and dimensions and decodes it with createImageBitmap. Conversion, compression and resize operations draw pixels to a Canvas and encode the result as JPG, PNG or WebP.
For JPG output, transparent pixels are composited onto white. JPG and WebP quality values are passed to the browser encoder, so result size can vary slightly across browser versions and image content.
PDF tools use different methods for different tasks
Operations such as merge, page extraction and reordering use pdf-lib to read page objects and build a new PDF. PDF.js is used where a page must be rendered or previewed.
PDF compression rebuilds pages as images, so selectable text, links and vector elements can be rasterized. Keep important original documents separately.
Office to PDF downloads and runs a browser LibreOffice engine
Word, PowerPoint and Excel conversion uses a browser LibreOffice engine instead of sending documents to a server. The first run can take longer because the WebAssembly engine and data files must be downloaded.
Those engine files are static site resources, not your document. The selected document is read as an ArrayBuffer in the current browser and passed to the local engine.
Files are not stored in an account or server file history
Tooldam has no user account or server database for storing file-work history. During normal use, selected files and results remain in browser memory and must be selected again after a refresh or after closing the tab.
The Office converter uses sessionStorage only for a one-time reload guard during engine startup; it does not store the contents of the selected document there.
How to verify it in Developer Tools
Open your browser Network panel, choose a file and run the operation. Upload-based services normally show a POST or PUT whose payload is close to the selected file size. Tooldam’s local-processing tools should not show a request uploading the file contents.
- Chrome/Edge: F12 → Network → enable Preserve log.
- Choose a file in a Tooldam tool and run the operation.
- Inspect Fetch/XHR requests and transferred sizes.
- Office conversion can show wasm/data downloads for the local engine.
Local processing has practical limits
Because server compute is not used, speed and workable file size depend on your browser, available memory and CPU. High-resolution images, long PDFs and large Office documents can use significant memory.
File limits and processing details are listed on each tool page. Measured compression and conversion examples are available in the test results.