PracticalKit shrunk to twelve flagship tools plus RGBV3D documentation. Each page declares a processing mode in the editorial footer: local, file/media, or third-party API. We removed tools that duplicated the same pattern without unique prose.
Local tools (hash, regex, JWT decode, JSON diff) execute entirely in JavaScript/WASM. Network calls should be limited to loading the app bundle. If you see unexpected POST traffic while using them, treat that as a bug and report via contact.
File/media tools (PDF, image, RGBV3D) read files you pick. Processing stays in-browser for the operations we implement; nothing is stored on PracticalKit servers because we static-host only HTML/JS.
Third-party API tools were mostly retired in this rebuild. Currency and translation pages redirected to /units/ with explanations. We would rather remove a thin API wrapper than maintain five languages of duplicate fluff.
Before pasting secrets, read the footer block on the specific tool. Generic site-wide claims are insufficient for auditors and users. This labeling scheme is part of the AdSense content-quality rebuild— transparency as primary content, not a link farm footer.
When adding tools again, each must ship with a handwritten guide (see tool pages) and a blog tie-in where depth warrants. No batch generator scripts.
Maintainer checklist before shipping a flagship: footer mode matches DevTools traffic; sensitive examples stay out of public screenshots; mode changes ship with About/Blog notes. Each API tool multiplies failure copy, quota text, multilingual risk notices, and tests—hence the aggressive retirement of thin wrappers. A small, explainable set beats a large, vague catalog for users and for advertising-quality reviews. When bookmarks hit retired routes, read the redirect page; never assume the old network path still exists. Mode changes are material product changes and deserve a dated blog note so auditors can reconstruct history.
2026-05-18