LightUtils's answer

The no-upload promise is enforced by the browser, not by our word for it.

Every page is served with a Content-Security-Policy containing connect-src 'none'. That directive means the browser refuses to let the page make any network request. Our own code could not send your file anywhere if it tried, and anyone can check it in about ten seconds:

1. Open the network tab
2. Use any tool on the site
3. Watch nothing leave

Almost every "private, client-side" tool on the web is a claim in a marketing paragraph. This one is a header you can read.

Two things follow from it. There is nothing to upload, so no queue, no round trip, and no file size limit that exists only because someone is paying for bandwidth. And there is no account, because there is no server to hold one.

LightUtils's answer

Because the documents most worth working on are the ones you should not hand to a stranger's server: a signed contract, a payslip, a bank statement, a customer list. On Smallpdf or iLovePDF those files are uploaded, processed remotely, and deleted on a schedule you have to trust. Here they never leave the machine.

Beyond that:

• Encrypted PDFs work. Files that open without a password prompt are handled. Most free tools refuse them, which quietly excludes bank statements, invoices and government forms.
• Five accessibility checkers almost nothing free offers: WCAG contrast, colour blindness, PDF accessibility, readability, and WCAG 2.3.1 flashing content.
• Genuinely bilingual. The Thai is written as Thai, not machine-translated, and Thai-specific problems are solved: CSV files that Excel opens as garbled Thai, and a readability checker that segments Thai words, which have no spaces between them.

LightUtils's answer

Two groups, and the second is the reason the site exists.

Anyone with a file and a task. Compress a PDF to fit an email limit, merge scans, trim a video, crop an image. They arrive from a search for that exact task and want it done in one screen.

People who are not allowed to upload the file. Lawyers, accountants, HR staff, clinics, and anyone working under Thailand's PDPA or the GDPR, where sending a document containing personal data to a third-party processor needs a legal basis rather than a convenience. For them "runs in your browser" is not a feature, it is the only way the task is permitted at all.

Geographically it is built for Thailand and the English-speaking world equally, which is unusual: most tool sites are English with a machine-translated Thai page bolted on.

LightUtils's answer

It started with a CSV file that Excel kept opening as garbled Thai. The fix is well known to developers and invisible to everybody else, and every free tool offering it wanted the file uploaded first. Sending a customer export to an unknown server to correct a text encoding is an absurd trade, and it is the trade almost every online tool asks for.

So the first tool was written to run in the browser. Then the harder question: how do you prove it? A promise in a privacy policy proves nothing. connect-src 'none' does, because the browser enforces it and anyone can read the header.

Once that constraint was fixed, the rest followed from it. No accounts, no server, no framework, no runtime dependencies. Fifty tools later the constraint has never been relaxed, and every claim on the site is checked by an automated test before it can ship, including the security header itself.

Built and maintained by CODENIVERSE, a software studio in Thailand.

LightUtils's answer

Deliberately almost none.

• Hand-written HTML, CSS and ES modules. No React, no framework, no bundler, no build step for the JavaScript.
• Zero runtime dependencies. The package manifest lists none at all. The only dev dependency is a property-testing library.
• Browser platform APIs do the work — WebCodecs for video and audio, WebCrypto for encryption and hashing, Canvas and OffscreenCanvas for images, Web Workers, and Intl.Segmenter for Thai word segmentation.
• No WebAssembly, by decision. It would have meant megabytes of download and a looser security policy.
• Written from the specifications, not pulled in as libraries — the PDF reader, PDF writer, PDF decryptor, ZIP writer, XLSX writer and MP4 remuxer are all ours. That is what keeps a tool page under 100 KB.
• Static assets on Cloudflare Workers. There is no application server.

LightUtils's answer

None, and it would be easy to invent some.

LightUtils has no accounts, collects no personal data and sets no analytics cookies, so we genuinely do not know who uses it — there is nothing on the site capable of telling us. That is the same decision as everything else here, and naming customers we cannot verify would undercut the one thing the product is for.