Documents · Freelance Invoice Tool
How to Check an Online Invoice Generator Isn't Sending Client Data Away
· How it works
invoice privacy browser-apis security
Invoice forms carry names, addresses, bank details and tax numbers, so it is worth knowing where they go. This post shows how to watch the network while you type and export, and how to read a site's Content Security Policy for third-party code.
Keystrokes are data too — why an invoice form can leak before you ever press export
A form can transmit data on each input event, long before an Export button is pressed. Names, addresses, tax identifiers and payment instructions are already sensitive when typed, so a useful check begins with an empty page and observes the whole session rather than only the final download.
Watching the Network panel while typing — spotting autosave or analytics requests that carry form contents
Open the Network panel, preserve the log and type harmless sample values into every relevant field. Inspect request payloads, query strings and destinations rather than relying on the request count alone. Local autosave should change browser storage without creating an application request carrying those fields.
Watching it during export — what a server-side PDF generator's request looks like compared with a local export
Keep the panel open during PDF and JSON export. A server renderer normally needs a request containing document data or an identifier for data already uploaded; a local renderer can create a Blob and download it without that round trip. The invoice source builds its PDF in the browser.
Reading Content Security Policy as one control, not proof that no external code runs
The outline overstates Content Security Policy: a policy can restrict script, font and connection origins, but its exact directives decide what remains allowed. It is one useful header to inspect, not standalone proof that no third-party code runs or that permitted code never reads a field.
Third-party scripts and what they see — why analytics and ad tags on a form page are a privacy question, not just a speed one
Analytics and advertising scripts deserve separate scrutiny because code executing on the form page can observe more than the PDF builder. The current invoice manifest disables both, and the limitations content forbids invoice fields in ToolAcre analytics events, while the broader blog documentation warns deployment can inject site-level analytics.
Worked example — a full check on the Freelance Invoice Tool from first keystroke to downloaded PDF
For a practical walkthrough, reload with the log preserved, enter invented values, inspect localStorage, generate both exports and search every request for those values. Repeat with browser extensions disabled if you need to distinguish page activity from extension traffic. Save the evidence, not just the conclusion.
What this does not cover — the security of your own device and browser extensions, which a website cannot control
This check cannot prove the safety of the operating system, browser profile, extensions, downloaded-file destination or later email workflow. It also observes one deployed version at one time. Confidential real data belongs in an offline workflow when page-level third-party code or device trust is unacceptable.
Takeaway — verify field handling without claiming the whole production page has no third-party scripts
The repository verifies local invoice processing, local draft storage and browser-built exports; it does not justify the workbook’s broader promise that an entire production page always has no third-party scripts. Check the deployed response and requests yourself, and describe only the field flow the evidence supports.