Your file's content is checked by software, not read by a person — with one disclosed exception: if a job gets stuck or hits a file type the system doesn't recognize, an operator may see metadata like a file's name or type to resolve it, never the content itself.
Why the absolute version of this claim is usually false
"No human ever touches your data, full stop" is a common claim in this industry, and for most real systems it's not quite true — something eventually breaks, gets stuck, or falls outside what the automation handles, and somebody has to look at it to keep the pipeline moving. A vendor claiming zero exceptions is either not disclosing the exception or hasn't hit it yet.
The actual boundary, stated plainly
Routine processing is entirely software-checked, start to finish. The one exception is operational, not investigative: a stuck batch or an unrecognized file type can put a job in front of an operator, who sees enough metadata to fix the pipeline issue — file name, type, size — and is never shown the document's actual content.
Where this breaks down — said plainly
- This exception exists precisely because it's disclosed, not despite it. A system that claims it can never happen is less trustworthy than one that names the one case where it does.
- Metadata itself can be identifying (a file named with a client's name, for instance) — if that's a concern, say so before submitting a job, since file-naming is in your control, not the system's.
Related guides
Where this fits on the site: this is part of how every job runs here, across all services. See Services & Pricing for what's actually sold, or go straight to Choose your job.