Security

This is the part most people want, so it comes first. When a tool needs server processing, the file goes through exactly these stages:

1. Transport. The upload travels over TLS. Nothing is sent over an unencrypted connection.
2. Isolation. A temporary directory is created for that single request. Your file is written there and nowhere else. Requests do not share directories, so one operation’s input is never visible to another.
3. Validation. The file type and size are checked before any parser touches it. Oversized submissions are rejected rather than truncated.
4. Processing. The tool runs. It reads the file, produces an output, and writes nothing outside that directory.
5. Return. The result is streamed back to your browser.
6. Destruction. The temporary directory is deleted, recursively, in the request’s cleanup path — which runs whether the operation succeeded, failed, or threw an error partway through.

If a process is killed between steps 4 and 6 — a crash, a restart — a directory can survive with nothing to delete it. A sweep runs every thirty minutes and removes any such leftover older than the retention window, one hour by default. That is a backstop for abnormal termination, and it is the only path by which a file lives longer than its request.

Not every operation needs a server, and the ones that do not, do not get one. These run entirely in your browser:

• Rendering pages to the screen and generating page thumbnails.
• Reading a PDF’s existing embedded text layer.
• Deciding whether a page is a scan or has real text — the check that drives the OCR PDF tool.
• Everything you do in the editor before you press Save: typing, moving, drawing, arranging pages.

For these, the document is never transmitted. A file you open, look at, and close without saving has not been uploaded at all.

Optical character recognition runs on our own servers, using an open-source engine we host ourselves. Your scan is not sent to a third-party recognition API, a cloud vision service, or any external model provider.

The recognised text is returned to your browser and is not retained by us. It is not logged, not indexed, and not used to improve anything — the operation record keeps the page count and how long it took, and none of the text.

Passwords are hashed with Argon2id, the memory-hard algorithm that won the Password Hashing Competition and is the current recommendation for new systems. We never store the password itself, and a database copy would not yield usable passwords.

Session tokens are stored as SHA-256 hashes. The token in your cookie is the only usable copy; our side holds only a fingerprint of it. Logging out revokes the session server-side, so a captured cookie stops working rather than remaining valid until it expires.

Session and identifier cookies are HttpOnly. Page scripts cannot read them, which removes the most common route by which a cross-site scripting flaw turns into a stolen session.

A request-rate limit covers every API endpoint, sign-in included, so a stolen password list cannot be replayed against the login route at unlimited speed. This is a ceiling on request volume rather than a lockout, which is why the point about password reuse below still matters.

Operational records are kept deliberately thin, and their contents are listed in full in the Privacy Policy: which tool ran, whether it succeeded, byte sizes, page count, duration, and a broad error category.

They contain no filename, no document content, and no extracted text. IP addresses are hashed with SHA-256 before being written to the usage store rather than kept in the clear. A log disclosure would reveal that operations happened; it would not reveal what was in them.

• Use a password you use nowhere else. Reuse is the single most common cause of account compromise, and no amount of hashing on our side protects an account whose password is already in a public breach list.
• Log out on a shared or public computer. The session cookie lasts 30 days and does not care who is sitting at the keyboard.
• Keep your originals. Every tool works on a copy, but nothing here is a backup.
• Check where you are. We will never email you asking for your password, and no legitimate message from us will ask you to send a document by reply.

If you have found a security flaw, we want to hear about it. Write to support@kovapdf.com with enough detail to reproduce it — the endpoint or page, the steps, and what you were able to achieve.

What we commit to

• We acknowledge reports within 5 working days.
• We tell you our assessment and our intended fix timeline.
• We tell you when it is fixed, and credit you if you would like to be credited.
• We will not pursue legal action against you for research conducted within the boundaries below, and we will not report you for it.

What we ask of you

• Test only against your own account and your own files. Do not access, alter, or retain anyone else’s data — if you encounter someone else’s data, stop and tell us.
• No denial of service and no traffic flooding.
• Do not run automated scanners at a volume that degrades the service for other users.
• Give us reasonable time to fix the issue before disclosing it publicly. Ninety days is our default, and we are happy to agree something shorter for a low-severity finding.

Every valid report gets credited.

If there is a breach that touches your data, we will tell you directly and quickly. The message will say what happened, what was involved, what has been done about it and what you should do — in plain words, and without waiting until every last detail is settled.