Local file processing
The core editing and conversion workflows are designed to process files in the browser on your device. In normal use, uploaded PDFs, generated files, selected page ranges, passwords entered for compatible lock or unlock flows, and similar workflow data are not sent to a remote document-processing server in order to complete the task.
That local-first design is the main privacy property of the product. It reduces exposure for sensitive files, but it does not replace your responsibility to secure your own device, browser, and downloads folder.
Analytics and consent
Optional analytics is not required for core PDF workflows and stays off unless you accept it. That analytics choice does not enable advertising. If advertising is introduced, it will use a separate consent flow appropriate to the visitor's region.
Analytics, when enabled, are intended for broad product measurement rather than document-content inspection. The goal is to understand usage patterns, not the private contents of a visitor’s files.
Advertising providers and their data use
DayFiles may use third-party advertising providers, including Google, on eligible web pages. Those providers may use cookies, web beacons, IP addresses, device identifiers, and similar technologies to deliver, measure, and limit advertising. They do not receive the PDF contents processed by the local tools as part of the document workflow.
Where regional law requires it, advertising consent is requested separately through an appropriate consent platform. You can read the domain-wide DayFiles privacy policy at https://dayfiles.com/privacy-policy/ and learn how Google uses data on partner sites at https://policies.google.com/technologies/partner-sites.
Cookies and local storage
The site may use local storage or similar browser storage for product settings, consent state, install-banner preferences, cached runtime assets, and offline capability. These are functional product behaviors, not hidden document uploads.
If you clear site data in your browser, preferences and offline assets may be removed. That can require the app to reload assets online before offline use is available again.
Offline caching
When the PWA service worker is active, the app caches the code and assets required to run supported tools offline after a successful online load. This includes scripts, styles, worker files, and other same-origin runtime assets needed by the application.
Offline caching improves availability. It also means application assets remain stored on the device until the browser evicts them or the user clears them.
Contact for privacy questions
If you have a privacy question, use the contact page. The best messages are specific about the behavior you want explained: local processing, cached assets, cookies, optional analytics, or offline install behavior.