How this site works
Who runs this site, why it exists, what the tools do on your machine, and the places where they stop being useful.
Who runs this
This site is independently operated and belongs to no larger company. There is no team page on this site because there is no team to put on one, and no founding year quoted anywhere because the site is new and the number would be doing no work for you. Nothing here is written by or on behalf of a sponsor.
Questions, corrections and bug reports reach whoever is running the site at kanchaishaoxia@gmail.com. That is the same address printed on the privacy policy and on the terms, and it is the only one. If something on a page is wrong, that is where to send it, and the page gets fixed rather than argued with.
Why this site exists
The tools here already exist elsewhere, several times over. What the existing ones have in common is that they are slow, buried under pop-ups and interstitials, and built to keep you on the page rather than to finish your task. Someone searching for a way to get a photo under 50KB wants to be gone in twenty seconds, and almost nothing serving that search is built for it.
So the whole proposition is being the fast, quiet one. Every page here is prerendered static HTML, the tool is the first thing under the heading, and the explanations sit below it where they stay out of your way. This site will carry display ads. It will not carry pop-ups, interstitials or anything that starts playing on its own, and if that ever changes the differentiator is gone and there is no reason left to use it.
Your files stay on your device
Every tool here runs as JavaScript in the tab you have open. Image compression uses a canvas, PDF parsing uses pdf.js, and text conversion is a lookup table. None of them send anything to a server, because there is no server to send it to and no upload endpoint anywhere on the site.
You can check that claim rather than taking it. Load a tool page, turn off your network, then compress an image or convert a PDF. It keeps working, which it could not do if a file were being transmitted somewhere.
No model is involved
The PDF converter reads the text layer already inside the file and applies typographic rules. Font size relative to the page's most common size decides heading level, a monospace font name marks a code block, and a bullet character starts a list. Every one of those is a deterministic test, which is why the same PDF gives you the same Markdown every time you run it.
This is worth saying plainly because most converters added in the last couple of years do call a model, which sends your document to a third party and bills you per page. Neither of those happens here.
Where the tools stop
- Scanned PDFs have no text layer. There is nothing to read and no OCR here, so the converter says so rather than handing back an empty file.
- Tables in PDFs are stored as positioned text with no row or column information. Simple tables survive, and complex ones need checking by hand.
- Styled Unicode text is read poorly or skipped entirely by screen readers. It is fine for decoration and wrong for anything a person needs to hear.
- Some images cannot reach a small target on quality alone. The compressor reduces resolution if you let it, and reports the size it actually reached if it still falls short.
- Compatibility notes on the text pages are inferred from how each Unicode block behaves rather than tested platform by platform. Where a table says so, treat it as a well-founded guess.
