What the measured run showed
These figures describe the controlled fixture documented for this guide. They are evidence for the tested case, not a universal performance guarantee.
Immediate conversions: one temporary working directory
For ordinary synchronous tools, the application creates a temporary working directory for the request, saves the uploaded source files there, runs the selected converter in that same temporary area, and opens the generated artifact for the download response.
When the response lifecycle finishes, a closing callback closes the output handle and removes the entire working directory. Validation failures, conversion failures, and unexpected exceptions also call cleanup on that temporary directory before returning the error response.
- The download response is sent with Cache-Control: no-store in the synchronous path.
- The temporary directory is removed after the response iterator closes.
- Known validation and conversion error paths remove the work directory immediately.
- This path is separate from the longer-lived queued job system used by heavier conversions.
Queued conversions: restricted job folders and explicit expiry
Heavier conversions such as PDF to Word use a queued job directory rather than the synchronous request directory. The application creates each job folder with mode 0700 and writes the uploaded source file with mode 0600. Completed output files are also set to mode 0600 before the job is marked complete.
The configured conversion job TTL in the evidence environment was 3,600 seconds. Expired job directories are removed by the conversion cleanup function, and the evidence fixture created an expired folder and verified that one expired conversion folder was removed.
- Job folders are UUID-addressed under the configured conversion job root.
- Source files are validated after upload before the job is queued.
- A failed job remains a failed job record only until application cleanup removes the directory.
- Opening a completed conversion result returns a cleanup callback that removes the whole job folder after the download handle is closed.
OCR jobs use the same temporary-storage principle
OCR jobs have their own job root and their own 3,600-second TTL in the tested configuration. The application creates each OCR folder with mode 0700 and the uploaded source with mode 0600, then writes the completed OCR output with mode 0600.
The OCR result opener returns a cleanup callback that closes the result handle and removes the job folder. The lifecycle evidence verified both removal after result download and removal of an expired OCR folder.
- Supported OCR jobs are stored separately from ordinary conversion jobs.
- Temporary OCR working files live inside the per-job folder while processing runs.
- The lifecycle test verified OCR download cleanup and expiry cleanup.
What our lifecycle test actually proved
The evidence harness did not merely inspect the cleanup functions. It exercised representative conversion and OCR result folders, invoked the result cleanup callbacks, and checked that the folders no longer existed afterward. It also created expired conversion and OCR folders and verified that expiry cleanup removed them.
That gives us direct evidence for the application-level lifecycle paths we tested. It does not prove that every possible operating-system crash, storage failure, network interruption, or infrastructure backup outside the application behaves identically.
- Conversion download cleanup removed the test folder.
- OCR download cleanup removed the test folder.
- Expired conversion cleanup removed the test folder.
- Expired OCR cleanup removed the test folder.
- Both configured TTL values were 3,600 seconds in the evidence run.
Temporary does not mean invisible while processing
A file has to exist long enough for the requested operation to run. During that period the application and the conversion or OCR process need access to the temporary source and output. Temporary processing should therefore be understood as bounded application storage with cleanup, not as a claim that bytes never touch server storage.
The permission modes used by the queued paths restrict the created job directories and files at the operating-system level, but permissions are only one layer of a secure service. This guide reports the application behaviour we inspected rather than claiming a complete infrastructure security certification.
What users should do with sensitive documents
If a document is highly sensitive, consider whether an online conversion service is appropriate for that file at all. Minimize unnecessary personal information, remove pages you do not need to process, and download and verify the result before sharing it further.
For documents governed by contractual, legal, medical, financial, or organizational requirements, follow the rules that apply to your situation rather than relying on a generic convenience tool as a compliance decision.
- Upload only the pages needed for the task when possible.
- Verify the output before redistributing it.
- Use local/offline tooling when your policy requires data to stay on your own device or network.
Limits of this evidence
This guide documents NetroDoc's application-layer temporary-file lifecycle as inspected and tested on 9 September 2026. It does not audit every host-level backup, filesystem recovery mechanism, reverse proxy, or third-party network component outside the application paths covered by the evidence harness.
The conclusion is therefore specific: the tested application paths created temporary storage with restricted permissions in queued jobs, removed tested result folders after download cleanup, and removed tested expired job folders at the configured TTL.
Temporary processing and privacy
This guide is itself the detailed privacy/lifecycle note. The controlled evidence verified cleanup in representative immediate/queued result paths and expiry cleanup for conversion and OCR jobs; the tested queued TTL was 3,600 seconds.
Read the Privacy Policy →Troubleshooting
Why does a queued job exist after processing finishes?
A completed queued result must remain available long enough to be downloaded. The tested path removes the job folder after result download cleanup, with expiry cleanup as a fallback for old folders.
Does temporary mean the file never reaches server storage?
No. The application saves a temporary source so the requested converter can process it. Temporary describes the bounded lifecycle and cleanup, not zero server-side bytes.
What if a browser download is interrupted?
The application has explicit response and expiry cleanup paths, but this evidence wave did not simulate every network interruption or host-level failure mode.
Method note
NetroDoc publishes measured claims only after a controlled run completes successfully. Untested cases are kept out of the conclusion. The evidence run for this publication wave used the same production runtime components while operating on an isolated candidate and temporary server paths.