Der Inhalt dieser Seite ist nur auf Englisch verfügbar.
About toolsbyus.com
Nur lokalBuilt on one premise: the file you are working on belongs in your browser, not on somebody else's server.
Why local processing
Files and data can contain private information. ToolsByUs offers local processing for PDFs, images, color, text and JSON, so a file-processing server is not required.
Before using any tool with sensitive material, try it with a sample and review its limitations. Follow your organization's data-handling requirements.
How ToolsByUs is architected
The guarantee is narrow and precise, which is what makes it worth anything: the content you put into a tool is never transmitted. The processing code reads the file locally and does not send its contents to a processing API.
- 100% Static Export: The entire application is pre-rendered into static HTML, CSS, and client-side JavaScript bundles using Next.js
output: 'export'. - Zero Backend Infrastructure: There are no serverless functions, no API routes, no Node.js backend processes, no database connections, and no authentication endpoints.
- Edge CDN Delivery: The build produces static files that can be served by an edge CDN. Hosting still handles ordinary connection metadata.
- Client-Side Isolation: Every parsing, validation, diffing, encoding, and schema generation algorithm runs entirely within your device's local CPU and V8/SpiderMonkey JavaScript engine.
- Dedicated Web Workers: Heavy work — a large semantic diff, a PDF merge, an image re-encode — runs in an isolated Web Worker under a 100 MB ceiling. The work still takes the time it takes; what the worker buys is a tab that stays responsive while it happens, instead of one that freezes.
Open architectural mechanics
Unlike black-box utilities, ToolsByUs uses transparent, standards-compliant engines:
- Iterative Stack Parser: Hand-rolled iterative parser capable of traversing 10,000 nested brackets without hitting browser call-stack overflow limitations.
- Semantic Diff Engine: Key-order-invariant comparison engine supporting RFC 6902 JSON Patch and RFC 7386 JSON Merge Patch specifications.
- JSON Schema Draft 2020-12: Real-time schema inference engine with automated format detection (UUID, email, date-time, uri, IPv4).
- RFC 9562 Monotonic UUID Generator: Browser cryptographic random generators for UUID v4 and database-optimized B-tree sequential UUID v7.
How this is paid for, and what that does not change
Advertising is disabled in this build. Analytics is configured separately; the privacy page reflects the current settings.
The tools do not include input contents in network requests. Third-party scripts running in the page have access to the page environment; a static export or CSP alone does not isolate input from those scripts. Any enabled integration must be reviewed by the operator. The privacy page sets out exactly which origins the browser is permitted to talk to, and how to check.
How these pages are written and reviewed
Every tool page carries a last reviewed date. It is worth saying what that date actually means here, because on most sites it means the day a script touched the file.
- The tool is built before the page is written. The explanatory prose describes behaviour that already exists in the code, which is why it tends to be about edge cases: those are what surface while implementing the thing.
- Claims are tested, not asserted. The “nothing is uploaded” claim is enforced by a Content-Security-Policy of
connect-src 'self'and checked by an automated test that fails the build if any request carries a body. Numbers quoted in the copy — size ceilings, page counts, output dimensions — are asserted in the test suite against real files. - Limits are documented rather than hidden. Where a tool cannot do something — schema
$refresolution, JWT signature verification, PDF password recovery, HEIC encoding — the page says so and explains why, instead of failing quietly. - A page is revised when its tool changes. The review date comes from the same catalogue entry that generates the navigation and the sitemap, so a page cannot claim a freshness its record does not support.
If something on this site is wrong, that is worth knowing: write to info@toolsbyus.com. The site holds no accounts, no uploads and no messages of its own — email is the one channel, and it only carries what you choose to send. Genuine defects and their fixes are documented in the changelog, which is the honest record of what changed and when.
The engineering philosophy
ToolsByUs is maintained by developers who build distributed systems, microservices, and web applications. We built the tools we wished existed: fast, zero-latency, private, and fully functional offline.
Who maintains the tools, and how are they checked?
ToolsByUs is the publisher of this collection. Tool documentation describes the implemented behavior, input limits and known edge cases. Each tool links to related operations, and every page publishes its content review date in its structured data and the sitemap.
The source includes unit tests for processing engines, browser tests for representative workflows, and build checks for links, metadata, structured data and security headers. Automated checks are useful evidence; they cannot guarantee every possible file or browser will work.
To check whether a problem you have noticed is already fixed, read the changelog. There is no private inbox: the site runs no accounts, accepts no uploads and stores no messages, so a defect worth fixing is worth describing publicly, and fixes land in the changelog. Never post private documents or credentials anywhere.
Review dates describe content checks. A shared layout change does not imply that every processing algorithm or article was independently reviewed on that date.