Security

1. Client-side processing is the core safeguard

When you open a PDF, image or office document in one of our tools, the processing code runs in your own browser on your own device. Merging pages, stamping a watermark, reading metadata, rendering a page and building the downloadable result all happen locally. The tool does not need to send the document to our server to do that work, and DocSample is designed so that it does not. A useful consequence follows: because we do not receive the file, we do not store it, scan its contents, train systems on it or expose it in a server-side breach of our tool storage. There is no DocSample account and no uploaded-file library for the tools.

Some features may download supporting program data to your browser — for example, OCR language data or a font file. Downloading that support file is not the same as uploading your document. Your document remains in the page on your device while the browser fetches the resource it needs.

2. What happens when you finish

The result is created in the browser and offered as a download to your device. Closing or refreshing the tab ends the working session and discards temporary in-memory data, subject to your browser’s own behaviour. The Invoice Generator and CV Generator can keep a draft in local storage on your device so that your work survives a refresh; that is storage under your browser’s control, not a server account. Clear the draft inside the generator or delete site data for docsample.com when you are finished, especially on a shared machine. Downloaded results are ordinary files on your device, so protect them the way you would protect the original.

3. Encryption in transit

DocSample is served over HTTPS, which encrypts the connection between your browser and the website’s hosting service. HTTPS protects the pages, scripts, blog content and support resources as they travel across the network and helps confirm that you are connected to the site named in the address bar. It does not make an already compromised device safe, and it does not encrypt a file after you download and send it elsewhere — for a sensitive attachment, use the recipient’s secure channel and consider the options in section 6 below.

4. Blog data and Supabase

Our published blog content is stored in Supabase and served to readers. That database contains editorial material — article text, titles, categories and dates — not documents processed in the tools and not invoice or CV drafts. Access to published blog material is limited to published content for public reading. Administrative access should be limited to people who need it, with strong, unique passwords and multi-factor authentication where available.

5. How we look after the site itself

We aim to keep the site’s software and dependencies maintained, to use reputable hosting and database providers, to limit administrative access, and to apply security updates made available for the platform. No online service can honestly guarantee that it will never be attacked or that every defect will be found before use. What our architecture does guarantee is a smaller blast radius for your paperwork: even a problem with the public website does not create a store of your uploaded documents, because the tools are not built around uploading them.

If we become aware of an incident that materially affects information we actually hold — such as contact emails — we will assess what happened, contain the issue, and notify affected people and regulators where the law requires us to do so.

6. Practical tips for sensitive PDFs

• Keep an untouched original. Work on a copy and open the downloaded result before sending it.
• Send less. If the recipient needs three pages, extract and send three pages rather than the whole file.
• Check metadata. Author names, software details and document properties can reveal more than the visible pages. Review the metadata before sharing a file externally, and remove it when it is not needed.
• Be careful with watermarks. A watermark identifies or discourages misuse, but it is not encryption. Do not rely on it alone to protect a trade secret or identity document.
• Use a password through a separate channel. If you protect a PDF with a password, send the password by a different route from the file, and use a strong, unique password.
• Mind the device. On a shared computer, download only what you need, remove generator drafts, clear site data, and delete local copies that are no longer required.
• Proofread OCR and edits. Searchable text created from a scan can contain recognition errors; a searchable document is not necessarily an accurate one.

7. Reporting a security problem

If you believe you have found a vulnerability in DocSample, please email hello@docsample.com with “Security” in the subject line. Tell us what you found, the page or tool involved, the steps needed to reproduce it, and what impact you observed. Please give us a reasonable opportunity to investigate and fix the problem before publishing details, do not access or alter data that is not yours, and do not test in a way that disrupts the site or other visitors. We appreciate careful, good-faith reports even though we do not operate a paid bug-bounty programme.

8. Questions

For general privacy questions, read the Privacy Policy or contact hello@docsample.com. For the terms that govern use of the tools, see the Terms & Conditions.