Private PDF tool

Contact PDFOmni

Send PDFOmni a support question, bug report, or suggestion at [email protected]. The on-site form prepares a message in the user's own email app.

Contact PDFOmni about private PDF tools, browser-based document workflows, bugs, feature requests, and support questions.

Before sending a bug report

Include the tool name, browser, device, approximate file size, and the steps that led to the problem. A screenshot is useful for layout, editing, or export issues.

The contact form prepares a message in the user's email app. It does not upload a message or document to PDFOmni by itself. Users can also write directly to [email protected].

What makes a bug report useful

Start with the result you expected and the result you actually saw. Then list the actions in the order you took them. For example, explain that you opened Edit PDF, selected a text block, changed one character, exported the file, and found that the text moved in the downloaded copy. A short sequence like that is easier to reproduce than a general message saying the editor is broken. If the problem happens only after dragging, double-clicking, changing the theme, or using a particular setting, include that detail.

Mention whether the issue appears in the working preview, the downloaded file, or both. Those views can use different rendering paths, so the distinction matters. Include the browser name and version when possible, the operating system, whether the device is a phone or computer, and an approximate page count and file size. Private content is not needed to explain most technical problems.

Sharing a safe test file

A small sample that reproduces the issue can be very helpful, but it should be safe to share. Remove names, addresses, account numbers, signatures, medical details, grades, client information, and anything else that should stay private. Covering information with a rectangle is not enough because the original text may still be present. Create a new sample from public or invented content when possible.

Before attaching a sample, reopen it in another reader and try searching or copying areas that were removed. Check the filename and document metadata too. If the bug only appears in a sensitive original and cannot be recreated safely, send screenshots of the interface and describe the document structure instead. A report can still explain that the page contains selectable text, an embedded font, a scanned image, a table, or a password without revealing actual information.

Reporting conversion problems

For a conversion issue, say which source format and output format were involved. Point to the kind of content that changed, such as a wide table, equation, unusual font, transparent image, link, header, footer, or multi-column page. Explain which office or PDF program you used to open the result because Microsoft Word, LibreOffice, Google Docs, and different PDF readers can interpret the same file in slightly different ways.

Screenshots should show the source and result at a similar zoom when the problem is visual. If text is missing, mention whether it was selectable in the source. If page previews are duplicated or out of order, include the source page count and the count shown by the tool. These details help separate an extraction problem from a display problem and make the fix more likely to apply to other documents too.

Reporting editing or export problems

Editing reports are most useful when they identify the exact action that changes the page. Say whether you clicked once, double-clicked, typed in the middle of a line, changed formatting, resized an image, or dragged an object. Note whether nearby text, borders, or background artwork changed in the canvas. Then explain what remained wrong after export, since temporary preview artifacts and permanent PDF changes need different fixes.

If the text appearance changes, include the original and displayed font size if the interface shows them. Mention symbols, spacing, alignment, and whether the text was part of a paragraph or several separate objects. A cropped screenshot around the problem is usually enough. Keep one screenshot from before the edit and one from afterward so the comparison does not depend on memory.

Accessibility feedback

Accessibility reports are welcome even when the PDF operation itself works. Include the control name or page section, how you reached it, and what made it difficult to use. Keyboard users can mention an invisible focus indicator, an unexpected tab order, a dialog that does not close with Escape, or a control that cannot be reached. Screen reader users can include the announced name, role, or status message that was confusing.

Contrast, zoom, reduced motion, touch target size, and mobile reflow are also useful areas to report. If an issue depends on a browser accessibility setting or assistive technology, name that setup. The goal is to fix the underlying structure and behavior, not hide an automated warning, so a description of what the person was trying to accomplish is especially valuable.

Feature requests

A helpful feature request begins with the document task, not only the name of a button. Explain what kind of file you start with, what has to change, and what the final result needs to do. Mention how often the task comes up and whether an existing PDFOmni tool solves part of it. This makes it easier to judge whether the idea belongs in a current workflow, needs a new tool, or depends on software that cannot reasonably run in the browser.

Privacy requirements matter too. If the feature would need a server, account, external API, licensed office program, or online AI provider, say what tradeoff would be acceptable for the use case. PDFOmni prefers local processing, and a feature should not quietly weaken that model just because a remote implementation is easier.

What support can and cannot do

Support can investigate reproducible site bugs, clarify how a tool is intended to work, and consider improvements. It cannot recover a password that was never stored, restore a file deleted from a device, provide legal approval for a signature, certify accessibility compliance, or decide whether a document meets a school, tax, court, employer, or government rule. Important submissions should be checked against the instructions from the organization receiving them.

There are no PDFOmni user accounts for the local tools, so support will never need an account password or ask for payment details to release a download. Be cautious with messages that claim otherwise. The official contact address shown on this page is [email protected].

After sending the message

Keep the original document and any safe test file until the problem is understood. If you discover a shorter set of steps or notice that the issue depends on one browser, reply to the same email so the details stay together. Do not keep sending sensitive copies. A corrected public sample is better for repeated testing and can be used without exposing the document that first revealed the problem.