About & Contact

Last updated: 19 October 2026 · Applies to vellum-pdf.xyz

1. Who runs this site

Vellum PDF is run by Amine. It is a solo project: one person who writes the code, designs the interface, hosts the site, answers the email and pays the bills. There is no company behind it, no team of writers, no agency and no investor.

The site is a side project, built in the evenings and at weekends alongside other work. It is not a commercial product in the sense that it has a sales team, a support desk or a service level agreement. What it does have is one accountable person, and that person is the one who answers messages and fixes the bugs.

That matters for you as a visitor, because it sets the scale of what you can expect. A feature request may take weeks. A broken conversion usually gets fixed sooner. If you write to us, you are writing to the person who wrote the code, not to a support queue.

2. Why it exists

The problem this site solves came out of ordinary work rather than ambition. Converting a PDF to images, merging two documents, or making a file small enough to email is a task that people need every week and that most web tools solve the same uncomfortable way: you upload the file to a stranger's server, wait in a queue, then download the result. Sometimes there is a sign-up, a watermark, a daily limit, or a page of adverts before the button works.

That model is fine for a brochure. It is not fine for a contract, a payslip, a medical record, a tenancy agreement or anything else you would rather not hand to a server you do not control. Uploading also means your document now exists in someone else's infrastructure, with retention rules you did not agree to and a privacy policy you have not read.

There is a second problem, which is closer to a design flaw than a policy: most of these tools require an installation. A heavyweight desktop application, a Java or Python runtime, a command line, an account. For a job that takes a minute, that is a poor trade. The work does not need a server, and it does not need to be installed either.

So the aim here was narrow and deliberate: put the four conversions that people actually repeat in one page, run them locally in the browser, keep them free, and never ask anyone to upload a document. If that means the site earns its keep from an advert below the tool rather than a subscription, that is a reasonable price to pay for the privacy and the absence of friction.

3. How it works

Nothing is uploaded. When you choose a file, the browser reads it from your disk using its own file API and hands the bytes to JavaScript libraries that are already running on your machine.

• pdf-lib does the structural work: assembling a PDF from images, joining existing PDFs in order, and rewriting the container when a file is compressed.
• PDF.js does the rendering work: rasterising each page of a PDF to pixels at the resolution you choose, so it can be saved as PNG or JPG.

Both libraries are open source and are loaded from a public content delivery network when the page first opens. Your browser caches them, so later visits work without a connection. The document itself is processed in memory in the tab, and the result is handed back to you as an ordinary download.

The practical consequences are worth spelling out:

• We do not receive your file, its contents, its name, or anything inside it.
• There is no upload size limit, because there is no upload. The practical limit is the memory your browser has available while rendering.
• No account is required and no personal information is collected in order to use the tools.
• Closing the tab disposes of the working copy, because no server-side copy was ever created.

The cost of this design is speed and memory. Rendering pages to pixels is the slow part of the job, and a very large document at 300 DPI needs a laptop rather than a phone. The tool page explains which setting to use for which kind of document.

4. How it is funded

Vellum PDF is a personal project, and its running costs are paid by the publisher. The site currently displays no advertising.

The tools are free and will stay free. There is no paid tier, no per-file charge, no file size limit to buy past and no upsell to a desktop application.

There are also things this site does not do. There are no affiliate links, so nothing you click is quietly paying us a commission. There is no data resale: nothing collected about you is sold to anyone, and no information about your documents is collected at all. Any future advertising would be governed by the privacy policy.

5. Editorial policy

Most of the text on this site is written by Amine, and Amine is responsible for it. The pages explain what the tools do, what they cannot do, and what happens to your files, and each of those claims is checked against the current behaviour of the code before it is published.

Where a statement describes a limitation, it is kept as a limitation rather than softened into a marketing line. Password-protected files, lossy compression, rendering differences against desktop applications and memory limits are all documented on the tool page, because a user who knows the limits is better served than one who discovers them mid-task.

To be transparent about how this text was produced: the pages on this site were drafted with AI writing assistance and then reviewed and edited by the publisher, who is the only person accountable for the final wording. No text is published without that review. Any factual claim about the tools can be checked against the behaviour of the tools themselves, and any claim that turns out to be inaccurate is corrected.

The publisher does not accept payment, free products or reciprocal links in exchange for a favourable description of a product, and does not publish advertorial written on behalf of a third party.

6. Corrections and bug reports

If something on this site is wrong, or a tool produces a wrong or broken result, it should be reported. Both types of report are useful, and both are handled by the same person who wrote the code.

Useful corrections to text are sent to the address in the contact section, quoting the page and the sentence in question. Useful bug reports include the information listed below under Contact, and attaching the source file when you are able to share it makes a diagnosis considerably faster.

Reports about a wrong conversion are treated as the more serious of the two, because a tool that produces a silently incorrect document is worse than a tool that fails visibly. If you have a good reproduction case, it will be used as a test case so the same failure does not come back.

7. Contact

Use the address that matches your message: general questions to hello@, bug reports and corrections to support@, and privacy requests to privacy@. If your message concerns the tools, it helps to include:

• The file type and the tool you used — for example "to images", "to PDF", "merge" or "compress" — and the settings you chose.
• Your browser and operating system, for example "Safari 18 on macOS" or "Chrome on Windows 11".
• What you expected and what happened instead, in that order. A description of the wrong output is worth more than a description of the wrong behaviour.
• The error message, if there was one, copied exactly rather than paraphrased.
• The source file, if you are able to share it and it is safe to do so. Please do not attach a document you need to keep confidential; a description of its structure is usually enough to reproduce a conversion fault.

Please do not send passwords, account numbers or other personal information by email. If your message concerns personal data, the privacy policy sets out the relevant request process.

For the rules governing your use of this site, see the terms of use.