Compare
Choose the safest BoringKit path for the job.
BoringKit tools are not all processed the same way. Compare local browser work, guarded URL checks, queued worker jobs, and API automation before sending files, URLs, or production workloads.
Local first
Use browser-side tools when supported.
Explicit upload
Worker jobs upload only after acceptance.
API fit
Automate only API-capable tools.
Browser-side tools
Small text, data, image, PDF, developer, business, and privacy utilities.
Input stays in the tab for supported local tools.
No API job. Use the web page.
Guarded server checks
URL metadata and Open Graph checks for public pages you are allowed to inspect.
BoringKit fetches through a protected path with unsafe URL rejection.
Use the dedicated endpoint when documented.
Worker jobs
Large files, document conversion, media export, batch work, and retained output.
Explicit upload after a job is accepted. Inputs and outputs are temporary.
Use /jobs for API-capable worker tools.
API jobs
Server-to-server automation, CI tasks, and repeatable utility workflows.
Scoped API keys own the request, job state, and download intents.
Use least-privilege keys, idempotency, polling, and webhooks.
Which BoringKit tools should I choose for sensitive small data?
Start with browser-side tools when the page says the input stays in the tab and the file or text fits the listed limits.
When should I use a worker job?
Use a worker job when the tool needs document, media, file, batch, retained output, or automation processing that cannot run safely in the browser.
Do all public tools support API jobs?
No. The tool catalog and API docs state which tools are in-browser, metadata-only, guarded server checks, or API-capable worker jobs.