← Back

Foliovex's whole design starts from one decision: your files are processed on your own device, not uploaded anywhere. Everything below follows from that, and is a factual description of what's actually implemented — not marketing language.

Files are processed locally

Every tool runs as JavaScript in your browser. A file you select is read and processed on your own device using your own device's memory and processing power. It is never transmitted to, or stored on, any server we operate — we have no technical ability to see the contents of a file you process here, because it never reaches us.

No account, no server-side storage

There's nothing to sign up for and nothing stored server-side tied to you, on any part of the site. Settings like your last-used watermark text or dark mode preference are kept in your own browser's local storage, on your device, not on a server. The Resume Builder works the same way at a larger scale — everything you enter (including an uploaded profile photo, kept as a plain image reference in that local storage) stays in your browser alone, so your draft resume persists between visits without ever being sent anywhere. The Hijri Calendar doesn't store anything at all; every date it shows is calculated fresh each time you load the page.

The one exception: the Speed Test

Every claim above holds for the PDF tools, Resume Builder, and Hijri Calendar without qualification. The Speed Test is genuinely different, and we'd rather say so plainly on this page than let its absence from the list above speak for itself: measuring a real internet connection requires actually sending and receiving real data, so that one tool exchanges disposable, meaningless bytes with Cloudflare's public speed-test network to produce a result. Nothing else — no files, no resume data, no dates you've converted, nothing from any other part of Foliovex — is ever involved in that exchange, and no other tool on the site makes any network request of this kind. The tool also keeps a history of your own past results, following the exact same pattern as everything else on this page: saved in your own browser's local storage, on your device, never transmitted anywhere — with a "Clear history" button that removes it for good.

Passwords are handled locally

The Password Protect tool encrypts and decrypts files using your browser's own processing — the password you enter is used locally and is never transmitted anywhere, logged, or stored. It exists only in your browser's memory for the duration of that operation.

HTTPS and transport security

This site is served exclusively over HTTPS, with HTTP Strict Transport Security (HSTS) enabled to instruct browsers to always use an encrypted connection to this domain.

Security headers

The following are actively set on every page:

• Content-Security-Policy — restricts which domains scripts, styles, and connections can load from, to a specific, deliberately short allowlist rather than a broad wildcard. Delivered two ways for one specific reason: most of the policy is set via a <meta> tag, but "frame-ancestors" specifically has to be set as a real HTTP header instead — browsers are required by spec to silently ignore that one directive when it's delivered via <meta>, so it lives in this site's HTTP headers alongside "X-Frame-Options" below, not because the rest of the policy is any less real.
• X-Frame-Options: DENY and frame-ancestors 'none' — this site cannot be embedded in an iframe on another site, which prevents clickjacking-style attacks.
• X-Content-Type-Options: nosniff — prevents browsers from trying to guess a file's type in a way that could be exploited.
• Referrer-Policy: strict-origin-when-cross-origin — limits what's shared with other sites when you navigate away from a link here.
• Permissions-Policy — explicitly disables browser features this site has no use for (camera, microphone, geolocation, payment APIs), reducing what could be exploited even in the event of an unrelated bug.

Third-party dependencies

The PDF processing itself relies on a small number of well-established open-source libraries — pdf-lib, pdf.js, JSZip, and the two libraries behind Password Protect's encryption — but none of them are fetched from a third-party CDN at runtime. They're bundled and served from Foliovex itself, from the same origin as every other file on the page, not from cdnjs, jsDelivr, or anywhere else. Processing a PDF never depends on a CDN being reachable, fast, or unblocked by a corporate proxy or ad blocker — the library is already here. The Resume Builder and Hijri Calendar have no third-party runtime dependencies at all — the resume builder's PDF export uses the browser's own built-in print function rather than a library, and the calendar uses the browser's own built-in date-handling engine, so there's nothing external for either of them to load.

Foliovex does use third-party services elsewhere on the site, for things unrelated to PDF processing — Google Fonts for the site's typography, and Google AdSense on pages where ads are enabled. Both are separate from, and have no access to, the local PDF-processing pipeline described above: they load typefaces and, where applicable, ad content into the page. Neither ever sees your file.

Handling of uploaded files

Even though files never leave your device, the tools still validate a selected file in two separate stages, not one. The first is fast and upfront: a PDF tool reads the actual bytes at the start of the file and checks for the real PDF signature, rejecting anything that doesn't match before any processing begins — a file renamed from ".jpg" to ".pdf", for instance, never gets this far, regardless of what its filename claims. But a correct signature only proves a file starts like a PDF; it says nothing about whether the rest of the file is structurally sound. That second stage happens naturally as the file is actually opened and processed: if a file is truncated, corrupted, or otherwise malformed further in, the parsing library itself detects that and reports it as a clear, catchable failure, which every tool is built to handle as an honest "something went wrong" message rather than a crash. The Resume Builder's photo upload follows the same first-stage principle for images — checking the file is genuinely an image and capping its size, rather than trusting an extension. The Hijri Calendar doesn't accept file uploads at all.

What happens to a file in memory after processing

Being honest about this rather than glossing over it: while you're on a tool's page, the file you're working with is held in your browser's own memory for that page, the same as any other data a web page works with. It isn't explicitly wiped the instant a download finishes — it's released the normal way any web page's memory is, by your browser's own garbage collection, when you navigate away from the page or close the tab. It was never written to disk or any persistent storage by Foliovex, and it was never accessible to us in the first place, since it never left your device — but "in memory during this tab" isn't the same claim as "wiped instantly," and we'd rather be precise about which one is actually true.

Reporting a security issue

If you believe you've found a security vulnerability in Foliovex, please report it to foliovex@proton.me. Include as much detail as you can (steps to reproduce, affected tool, browser/OS) so it can be investigated properly. We ask that you give us a reasonable opportunity to address an issue before disclosing it publicly.

Related

See the Privacy Policy for how any optional analytics or advertising on this site is handled.