We Closed the PDF Tool. Our File Was Still Downloadable Nearly 4 Hours Later.

• PDFgear delivered three different documents beyond our conservative departure benchmark: one on 15 October, and two on 16 October with different departure methods. Fresh no-interception browsers reproduced all three. Its page gives conflicting immediate-download, closure/refresh and 20-minute departure descriptions; we used the longest explicit delay, with an additional 15-minute grace period. PDFgear compression tool.
• One iLovePDF pilot remained downloadable about 143 minutes after its initial download, beyond the two-hour processed-file description and our grace period. A separate main file was inaccessible at a much later check the next day; a separate late-only file was also inaccessible after 24 hours. These different files and timings do not locate the first file’s expiry. iLovePDF security, FAQ.
• Inaccessible URLs did not demonstrate erasure. Smallpdf’s saved URLs explicitly reported expired requests. Sejda and Online2PDF returned HTTP 200 HTML rather than our PDFs. Status codes alone would have misclassified these observations.
• One exact synthetic filename appeared in a FreeConvert request to Microsoft Clarity. No document-text marker, embedded metadata marker or complete source bytes matched that request. Independent reproduction remained incomplete. This is a single filename observation, not evidence that Clarity received the PDF.

All assigned measurements ended on 16 October. The original plan was shortened: two additional main days and a seven-day observation were withdrawn. The article reports the resulting two-date investigation and one main collection day, with those limits intact.

PDFgear’s compression page describes several cleanup events. One passage refers to removal after downloading; another to closing or refreshing the browser; a tooltip describes a 20-minute delay after leaving. We did not choose the shortest promise to manufacture a discrepancy. Before checking, we adopted the longest explicit departure delay and added 15 minutes. PDFgear compression tool.

The first pilot’s isolated context closed on 15 October. About 53.28 minutes later, both a client restoring the original session and a separate client without its cookies received the marker-verified output. A fresh browser then downloaded identical bytes. The response’s MIME type was text/plain; its actual bytes were a valid PDF. Relying only on the MIME label would have missed it.

On 16 October we created two independent synthetic files. Both had successful original-session and fresh-client baseline requests before departure. For one, we closed the isolated context. For the other, we navigated the normal page to about:blank, verified that navigation, then closed it. We did not call a hidden deletion endpoint or press a permanent-delete button.

The first later checks occurred 231.30 minutes after closure for the first file and 230.96 minutes after closure for the navigate-away file. Both clients received each original output again. A separate new browser reproduced each SHA-256 and content marker, with cache disabled and no disk-cache, service-worker or prefetch-cache flag on the matching network response.

This adds a distinct-day observation and a second departure method. It does not establish a provider-wide failure rate. There is one main file per departure condition, and neither method proves the server received or handled a departure notification. The requests establish remote delivery; they do not identify whether it came from origin storage or a CDN, or whether original uploads were retained alongside generated outputs.

The archived iLovePDF security page describes removal of processed files within two hours. The FAQ frames the period around availability for download. We retained those clock differences and used the later initial-download time as a conservative pilot anchor. Security statement, download/deletion FAQ, deletion guide.

At 143.17 minutes after that initial download, both clients received the correct 153,203-byte PDF. A new browser, without the capture proxy or prior cookies, reproduced the same hash. This is a reproduced discrepancy with the two-hour processed-file description, subject to the statement’s scope and clock ambiguity.

The next-day main output had a successful same-output baseline. It returned a task-removed response at 339.89 minutes after baseline completion. A different, late-only pilot file returned a task-removed response after more than 24 hours without intervening access.

Those negative observations do not cancel the earlier positive result. They also do not show that the first pilot survived until the main check. Different files, different access histories and different elapsed periods cannot be stitched into a single retention curve.

On small screens, scroll each table horizontally to see all columns. The following tables use the first original-session request’s start time. Original-session and fresh-client outcomes agreed on PDF delivery at every timed checkpoint. Times are elapsed from the stated anchor, rounded to two decimals. A negative result means our PDF was not delivered by that saved URL at that check.

15 October early pilots

Independent late-only pilot files, checked 16 October

16 October main duration cases

Separate exploratory count condition

PDF24’s main file had no initial download: its ordinary Download request was locally held and aborted before reaching the capture proxy. Its first real retrieval attempt returned a missing-job response about 263.62 minutes after observed processing. A different pre-deadline control had already demonstrated that restoring the original session could retrieve a PDF24 output, while a cookie-free client received 403. That control is why a fresh-client refusal alone would be insufficient evidence.

Smallpdf’s main baseline succeeded in both clients. Its later URL returned ExpiredRequest, an explicit request-validity result. Its browser-local blob download had been matched by SHA-256 to the actual remote PDF response before we selected that remote URL for testing. A blob address itself is not a remotely retrievable file link. Smallpdf compression tool, privacy policy.

Online2PDF’s privacy page distinguishes uploaded originals, described as removed after conversion, from generated outputs described as available for up to 90 seconds. We tested the generated output only, using later baseline completion plus 90 seconds and 15 minutes of grace. Its much later first check returned HTML/200. This does not test its separate original-upload claim or establish that the output expired within 90 seconds. Online2PDF privacy.

Sejda’s original-session browser followed a redirect to an editor with a “File expired” banner. HTTP 200 was a page response, not document recovery. PDFCandy returned 404 HTML. Their two-hour descriptions remain source claims, not independently proved storage erasure. Sejda compression tool, PDFCandy compression tool.

FreeConvert’s exact normal download anchor was first verified by an original-session request baseline. The earlier browser click had produced no saved download event before closure; the fresh-client baseline timed out. Its later check, 705.32 minutes after baseline completion, returned 404 HTML in both modes. The earlier timeout remains unknown accessibility, not a denial. FreeConvert privacy.

We froze a purposive candidate list rather than sampling market share. We attempted anonymous compression across all twelve, conserving free quotas and stopping at account, access or workflow barriers. There were thirteen main workflow records because PDFgear had two independently specified departure conditions.

CloudConvert illustrates why source reconciliation matters. Its security page describes removal after processing, while the privacy policy specifies an automatic maximum of 24 hours. We retained the explicit outer policy bound and withdrew a proposed shorter comparison before any such expiry check. We did not label a still-working pre-deadline output a failure. CloudConvert security, privacy.

Xodo’s ordinary picker retry selected the same specimen twice. The offered single-file continuation still left duplicate cards; we saved one existing output. Both copied storage-URL clients received AccessDenied before expiry. That makes this method unevaluable for expiry, regardless of later availability. Duplicate selection is a workflow confound, not two independent files. Xodo compression tool.

Soda PDF showed an internal-server-error message during ordinary selection. One bounded no-interception retry showed the same UI message. We did not verify an output or infer an HTTP 500, an outage, or its cause. Its stated 24-hour horizon also lay outside the remaining collection window. Soda PDF compression tool.

PDF2Go delivered one normal browser download and nine additional, prospectively bounded original-session file requests. All ten observed deliveries matched the same PDF. A later original-session request, fresh-client request and new browser also retrieved it.

This remains an exploratory result. The copied final download URL differed from the result page’s observed anchors, so direct deliveries do not establish increments in a provider’s UI download counter. More importantly, the final audit could not substantiate the “24 hours or ten downloads” benchmark recorded in earlier notes: the archived educator-page HTML does not contain that wording, and no separate saved rendering establishes it. We preserve the original plan and record this correction rather than turn an unsupported benchmark into a headline. The reviewed current security page is nonnumeric. PDF2Go security, archived educator-page source URL.

The sequence is exported separately in download-count-control.json. It is neither a completed 24-hour retention test nor evidence of a broken ten-download promise.

After the FreeConvert processing/download workflow, one captured POST to e.clarity.ms contained the complete synthetic filename. The 1,785-byte request body did not match our unique visible document text, author-metadata marker or complete source file bytes. Its timestamp and body hash are preserved; public exports omit access URLs and cookies.

Microsoft describes Clarity as analytics and session replay. FreeConvert’s archived policy names analytics/feedback providers, including Google Analytics and HotJar, but our text review found no Clarity-specific name. That is a narrow name-and-function comparison, not a legal assessment of disclosure adequacy. Generic and linked disclosures must also be considered. Microsoft Clarity data, session recordings, FreeConvert privacy.

We tried independent no-interception probes. Selection alone did not reproduce the match, including after decoding observed gzip payloads. An attempted full-workflow probe did not reach the ordinary processing button and remained incomplete. Neither is a matched negative replication of the original completed workflow. We therefore report one positive filename observation without independent reproduction.

Our privacy-request form investigation also distinguishes metadata from the document or request a user intends to send. A filename can itself reveal context in real use; our specimens contained only invented identifiers. This study does not show that Clarity received PDF contents, how long the filename was retained, or that it was sold, used for training or unlawfully disclosed. General Clarity retention documentation cannot establish retention of this particular request.

A recipient domain is not enough to establish document disclosure. We looked for exact source bytes, independent text/filename/metadata markers, or verified output-response hashes, then classified the observed function.

The limited Smallpdf purpose comparison is grounded in the archived privacy section. We do not turn a provider-name mismatch or a functional storage host into an allegation of undisclosed sharing. Smallpdf privacy. Full recipient records and transport evidence are in the sanitized exports.

PDFCandy sent the source in chunks of 1,000,000 and 184,099 bytes; ordered concatenation exactly matched the 1,184,099-byte source. Sejda used a ZIP container with an encryption flag, AES extra field and matching uncompressed length. These cases explain why raw substring scans alone undercount uploads. A missing text marker is not a no-transfer finding.

We used harmless one-page synthetic PDFs with deterministic image data and separate filename, visible-text and embedded metadata markers. No personal documents, signatures, third-party records or account credentials were uploaded. Anonymous compression was the common operation; each operation and exception remains labelled.

The isolated Chrome/Playwright capture environment was validated against local receiver ground truth. HTTP and HTTPS lifecycle fixtures exercised multipart and binary upload, correct PDF download, HTTP-200 error-page rejection, expiry, deletion, cache and session isolation. Separate worker/service-worker/frame/departure rounds matched all 17 receiver probes through the proxy; browser events missed the two departure beacons. HTTPS lifecycle controls were revalidated before main collection. These controls validate specified mechanisms, not every browser transport or application encoding.

Retrieval checks used normal TLS without capture interception, original saved session state and a separate fresh request client. Each saved response has timestamps, byte length, SHA-256 and PDF/text verification. All five positive timed cases received an additional same-job browser reproduction without interception. Fresh browser evidence is separate from independent file replication.

Where needed, the source response hash identified a browser download. A 200 status, visible thumbnail, expired blob address or downloaded HTML page never counted as a recovered PDF. Fresh API clients avoid prior browser cache; browser reproductions use fresh contexts, and the four navigation-based reproductions record cache-disabled network flags. Remote CDN delivery counts as retrievability without proving origin storage architecture.

Main same-output baseline controls deliberately touched the files. We conservatively moved the timer anchor to the later baseline completion; PDFgear used the later context closure. This amended design conserved free quotas while proving copied-URL client fidelity, but it cannot estimate untouched retention. PDF24 held-download jobs and the independent 24-hour cohorts remain separately labelled. We did not poll files between their assigned observations.

Several first checks occurred three hours later than planned. We kept actual host timestamps and later elapsed periods, rather than presenting intended schedules as observations. Clock wording, network latency and the interval between observations prevent exact deletion-time estimates.

The sample is purposive and small. Six early pilots and three independent late-only jobs are separate from nine main duration cases across eight providers. The ninth main duration case is PDFgear’s second departure condition. PDF2Go’s one count-conditioned case is separate again. Eleven baseline-control jobs, including the separate PDF24 fidelity control, are controls, not expiry outcomes. Two metadata-only probes are not additional processing cases. There are 26 saved workflow records, not 26 comparable deletion tests.

There was only one main calendar day. Six providers had pilot collection on the previous date, but the access methods and checkpoint times were not identical. No seven-day result, three-day main replication or live permanent-manual-deletion result exists. The local fixture’s manual deletion control does not substitute for a live provider test. Proton was available but was not needed for a concrete route comparison; no VPN or geography effect was measured. Our separate VPN website-warning study and location-based cookie-choice investigation address different questions and are not evidence for file deletion.

Consent/UI choices and technical retries are saved with the workflow evidence, but this was not a randomized consent study. We cannot separate every possible cookie, region, load, cleanup-queue or account-tier effect. No provider has reviewed these observations or answered the locally drafted questions; no outreach was authorized. The final claims remain observations with unresolved mechanisms.

Related investigations have examined converter uploads and online-service erasure. Our contribution is the dated, synthetic-file claim-versus-retrievability record, independent late-only cohorts, positive byte verification and transparent failed methods. We do not claim to be first. A broader account-erasure study uses a different design and should not be treated as validating these file outcomes. Leave No Data Behind, PoPETs 2022.

For readers, a deletion promise and an expired download link answer different questions. When document sensitivity matters, choose a workflow whose processing location and storage behavior you can assess; an established offline workflow avoids sending that document to a web processor. This study does not rank offline products or certify any provider as safe. Our guide to what VPNs cannot protect explains why securing a connection does not control what an upload recipient retains.

For tool builders, useful deletion language identifies the object, the clock and the boundary: original upload or generated output; processing, download, last access or departure; link expiry, output cleanup or backup retention. A closure-based promise should describe what happens when a departure signal never arrives. Analytics should minimize filenames as well as document contents. These are design implications, not proven explanations of our results.

For researchers, a useful next study would keep identical independent conditions across more days and networks, verify any provider counter through the ordinary UI, and test separately authorized manual deletion. Those experiments were not performed here and fall outside this study’s collection window.

The same distinction between a secure connection and recipient-side handling appears in our VPN-tunnel advertising investigation and password-checker query study. These are separate experiments, not evidence of PDF content sharing. Our privacy-policy content guide explains how recipients and retention should be described.

The accompanying package contains sanitized JSON/CSV, all nineteen timed job observations, source URLs/timestamps/hashes, reviewed image provenance, public analysis and collection code, the original protocol and dated corrections. Exact download URLs, cookies, private captures, raw provider pages and keys are excluded. The self-contained HTML embeds the same charts and selected reviewed images; all article text is also available in Markdown.

Sanitized evidence and reproducible code · Final observations CSV · Machine-readable counts · Reproduction instructions

Research scope: findings describe the measured 15–16 October 2026 window and may not describe later service behavior. No provider outreach was performed.