Security and data handling

The short version

• The converted file comes back in the API response. We store it only if you send StoreFile=true.
• A stored file's download link works for 3 hours. A cleanup job runs every 15 minutes and deletes files whose links have expired.
• The containers that run conversions have no internet access and run as a non-root user.
• An API key is shown once. We store only its SHA-256 hash and last four characters, and accept keys only in the Authorization header.
• We don't have a SOC 2 report or an ISO 27001 certificate, and we can't sign a HIPAA business associate agreement. Don't send health records.

This page describes the hosted API at https://api.pdfconversionapi.com. The service is new, so what follows describes the code and configuration we deploy, not a track record. Every number here comes from that code and configuration, or, where our cloud provider runs that part, from the provider's documentation. The provider is listed on the subprocessor page. When the code changes, this page changes and the date at the top moves.

How a request travels

1. Your request reaches our cloud provider's network over HTTPS.
2. The API gateway, which runs on that network, checks your API key and applies your account's rate limit (600 conversion requests per minute). It then applies your plan's limits: conversions a month, conversions at once and the largest request, counting all files and fields together. No plan allows a request over 100 MB.
3. The gateway sends the request over HTTPS to our conversion service, on the same provider's network, which passes it to a conversion container. There are three pools, split by engine: the first runs the converters inside the server process together with the Word, PowerPoint, CAD, PDF and image engines and the JPEG XL encoder; the second runs the office suite; the third runs the browser engine. The containers have no public address, and the conversion service refuses every request without a key that only the gateway holds; the containers check the same key.
4. The converted file goes back through the gateway to you, base64-encoded in the JSON response. With StoreFile=true, the conversion service writes it to object storage in our provider's US jurisdiction instead, and you get a download link on https://api.pdfconversionapi.com.
5. For each conversion request that reaches a container, the gateway records one usage event: formats, status, duration and upload size. No file data.

All of this runs on our cloud provider's platform. No other company and no other server receives your files. The subprocessor list names the provider and has the details.

What we keep, and for how long

Uploads up to 25 MB stay in the gateway's memory for the length of the request, so a busy container can be retried with the same bytes. Larger uploads stream through once. Container disks don't persist: when an instance stops (after 10 minutes without requests, or when we deploy a new version), its disk is discarded.

The lifecycle rule exists in case the cleanup job stops running. Our provider documents that it applies lifecycle rules typically within 24 hours of the expiry, so in that failure case a stored file could last about 48 hours. While the cleanup job runs normally, a stored file is gone within 15 minutes of its link expiring.

Delete a stored file before it expires

You don't have to wait for the 3 hours. DELETE /v2/d/{FileId} removes the file at once. It needs the API key of the account that created the file; any other key gets a 404. This example uses curl, jq and our sample Word file:

curl -sS -X POST \
  https://api.pdfconversionapi.com/v2/convert/docx/to/pdf \
  -H "Authorization: Bearer $PDFCONVERSIONAPI_KEY" \
  -F File=@input-quarterly-report.docx \
  -F StoreFile=true \
  -o response.json

URL=$(jq -r '.Files[0].Url' response.json)
FILE_ID=$(jq -r '.Files[0].FileId' response.json)

# The link works without a key until it expires.
curl -sS -o quarterly-report.pdf -w "%{http_code}\n" "$URL"

# Delete the stored file now instead of waiting.
curl -sS -X DELETE -o /dev/null -w "%{http_code}\n" \
  "https://api.pdfconversionapi.com/v2/d/$FILE_ID" \
  -H "Authorization: Bearer $PDFCONVERSIONAPI_KEY"

# The same link now returns 404.
curl -sS -o /dev/null -w "%{http_code}\n" "$URL"

200
204
404

Isolation per conversion

A file converter reads files made by strangers, so we treat every upload as hostile. This is what each conversion runs inside today, and what it does not have yet.

Every conversion

• Engines that run as separate programs (the Word, PowerPoint, CAD, PDF and image engines, the office suite, the browser engine and the JPEG XL encoder) get a new temporary folder for each run, deleted afterwards. Their environment is cleared except for a search path, a language setting and folder locations that point into that temporary folder, so no secrets from the server reach them. They get no standard input, and we read back only a capped amount of their output.
• Each of those engines runs in its own process group. At the 120-second limit we stop the engine together with every helper process it started.
• Your file is written into that folder under a fixed name. The file name you sent is never used as a path on our side. Engine error messages have server paths removed before they reach you.
• The converters that run inside the server process work in memory. A converter that hits an internal fault on a malformed file returns an error instead of taking the server down.
• Limits are checked before the work: requests up to your plan's upload size (100 MB at most), images up to 100 million pixels (checked before decoding), any PDF stream at most 256 MB once decompressed, ZIP archives at most 10,000 entries and 1 GB unpacked. ZIP entries keep only their base name, so an archive can't write outside its folder.
• Output is capped at 2,000 per request: pages or DICOM frames rendered as images, pages in a merged PDF, files split from a PDF, and pages laid out as PDF from HTML, email or e-books, whether inside the server process or by the browser engine. Those can only be counted after layout, so a longer document is refused with a 413 once it has been laid out.

No network

• The conversion containers start with internet access turned off.
• We don't fetch URLs for you. The Url parameter is refused with a 400, so the converters never make requests on your behalf.
• HTML is laid out by a layout engine inside the server process, which reads no files and makes no requests. Pages that need a real browser go to the browser engine, started fresh with a new profile for each conversion and served only your uploaded page. Every other request the page makes (images, scripts, frames, navigations) is refused, and behind that the browser engine has an unreachable proxy and no DNS. Our end-to-end tests convert pages that point at file:///etc/passwd and http://169.254.169.254/ and check that neither appears in the output.
• The office suite gets a new profile for every run, with document macros turned off, and opens each file with the import filter for its declared format only. It refuses external content such as linked files and WEBSERVICE formulas. An end-to-end test converts a CSV whose formula points at a server file and checks that nothing from that file comes back.
• SVG files can load only images embedded as data: URLs, never files from the server.
• CSV to XLSX never writes a formula: a cell that starts with = stays text.

The containers

• Each container instance runs in its own lightweight virtual machine with its own kernel, which our provider does not share with other workloads.
• The conversion server runs as an unprivileged user (uid 10001), not as root.
• When the image is built, each of the five downloaded engine archives is checked against the SHA-256 checksums its project publishes, and the two OCR models against checksums pinned in our build file. A mismatch stops the build. The office suite, the browser engine and the other system packages come from a Linux distribution's package repository, and the package manager checks them against the distribution's signed package index.
• Instances are shared between accounts. One instance runs up to 2 conversions at a time, and they can belong to different customers. Between two conversions in the same instance, the separation is the per-run folder and process described above, not a separate virtual machine.

Not yet

• A read-only root filesystem, dropped Linux capabilities and no-new-privileges on the hosted containers. Our container configuration on the provider's platform does not set them, so we don't claim them.
• Extra kernel-level sandboxing, such as a user-space kernel or seccomp profiles.
• The browser engine's own sandbox. It needs privileges the container doesn't grant, so the browser engine we use for HTML runs with its own sandbox turned off and the container is its boundary.

Encryption

• In transit: requests to https://api.pdfconversionapi.com use HTTPS between your server and our cloud provider's network. The step from the gateway to the conversion service also uses HTTPS, on the provider's network, and carries a key that only the gateway holds; the containers have no public address.
• At rest: stored results in object storage are encrypted with AES-256, as our provider documents for that storage.
• Not end-to-end encrypted: the converter has to read your file to convert it.

Access control

API keys

• A key is accepted only in the Authorization: Bearer header. A key in a URL or query string is not accepted.
• You get a key by signing in with Google or GitHub at app.pdfconversionapi.com. The key is shown once. We store its SHA-256 hash and last four characters, and the gateway checks keys against the hashes in a key-value store run by our provider, with your account id and plan. We don't keep the key itself, so we can't show it again. If you lose it, replace it.
• "Replace the key" on the same page revokes the old key. Deleting your account there deletes the key. The gateway caches key lookups for up to a minute, so a revoked or deleted key stops working within about a minute and then gets a 401 on every request. If you think a key has leaked, replace it, and if you can't sign in, email security@pdfconversionapi.com.
• Each account can send 600 conversion requests per minute. Over that, the API answers 429 with Retry-After: 10.
• Each plan also sets conversions a month, conversions at once and the largest request. Going over gets a 429 or a 413. The error list has the messages.

Account pages

• The account pages at app.pdfconversionapi.com are a separate small app on our cloud provider's platform. When you sign in with Google or GitHub, we keep only your verified email address and that account's id. Each verified email address has one account.
• Signing in sets a session cookie that lasts 30 days. We keep only a SHA-256 hash of it.

Stored-file links

• The id in a download link is 32 hexadecimal characters (128 bits) from a cryptographic random number generator.
• Downloads are sent with Content-Disposition: attachment, Content-Security-Policy: sandbox, X-Content-Type-Options: nosniff and Cache-Control: private, no-store. A stored HTML or SVG file can't run scripts on our domain, and shared caches don't keep a copy.
• Only the account that created a file can delete it early.

People

A file returned in the response is not kept anywhere after the request, so no one can read it later, including us. Stored files, logs and usage events can be read by the people who operate our account with our cloud provider until they are deleted.

Logging

What we record:

• API gateway, up to 7 days. For each request to the gateway, the provider's request logs keep an invocation log, which the provider describes as the request, the response and related metadata. It can include your IP address, approximate location and user agent. Our own log lines add unexpected gateway errors (request id and error text) and the cleanup job's count of deleted files.
• Conversion containers, 7 days. One line per conversion with the format pair, the number of output files and the seconds taken, or the reason a file was rejected. Our provider keeps container logs 7 days.
• Account pages, errors only. The account pages have per-request invocation logs turned off, so signing in leaves no log entry unless the app fails.
• Usage events, 3 months. One per conversion request that reaches a container: account id, plan, source and target format, container pool, HTTP status, duration in milliseconds, upload size in bytes and whether it succeeded.

What we don't record: the contents of your files, the parameters you send and the names of the files you upload. Two exceptions to know about:

• When a file is rejected, the error message goes into the log, and some messages quote a detail from the request or the file, such as a parameter value, a worksheet name, a path inside an archive or, for images/to/pdf, the name of an uploaded image that could not be read.
• A download link contains the stored file's id and name, so both appear in the gateway's request log when someone uses the link. Until the link expires, anyone who can read our logs could use it.

Our provider also keeps its own records of traffic to our domains, such as traffic statistics and security events, for periods the provider sets.

Every API response has an x-request-id header. Quote it, with the time of the request, when you report a problem.

What we don't do with your files

• We don't use them to train or improve any model. The only models in the service are the two OCR models, which were trained before your file arrived, are pinned by checksum, and only read your pages to recognize text.
• Nothing in the service sends your files anywhere except back to you, and to object storage when you ask for storage.

Where data is

• Processing happens on our cloud provider's network. The gateway normally runs in the provider's data center that receives your request. A container instance starts in the nearest location that has our image ready and keeps serving from there while it runs, so a conversion can happen in a different country from the one you call from. We can't pin processing to a country or region yet, and there is no EU-only option.
• Stored results stay in the United States: the storage bucket was created in our provider's US jurisdiction, which the provider says keeps the data stored and processed in the US.
• Logs, usage events, key hashes and account data (email addresses, Google and GitHub account ids, and session hashes) are kept by our cloud provider. We have not pinned them to a region.

Compliance status

• We don't have a SOC 2 report.
• We are not ISO 27001 certified.
• No third party has run a penetration test on the service yet.
• We are not HIPAA compliant and can't sign a business associate agreement (BAA). Don't send protected health information (PHI). The acceptable use policy forbids it.
• We are not certified under the EU-US Data Privacy Framework.
• We offer a Data Processing Addendum for personal data inside the files you send, covering GDPR Article 28 and US state privacy laws. It applies automatically as part of the Terms.
• Billing is not open yet, so we hold no payment card data.

If your vendor review needs a security questionnaire answered, send it to security@pdfconversionapi.com.

Subprocessors

Our cloud provider is the only company that handles the files you convert. An email provider hosts the inbox our published addresses forward to. The subprocessor list names both, shows what each service handles and where, and explains how we announce changes.

Incidents

If a security incident affects your data, we email the contact address on your account without undue delay, and within 72 hours of becoming aware of it, as the Data Processing Addendum sets out. The email says what happened, what data was involved, what we have done and what we suggest you do, and who to contact.

There is no public status page or uptime commitment yet. We will link the status page here when it exists.

Reporting a vulnerability

If you find a security problem, email security@pdfconversionapi.com. The disclosure policy explains scope, what we promise in return and the good-faith protection we give researchers. The same contact is published in machine-readable form at /.well-known/security.txt.