Local Mac utilities vs online tools: what should stay offline?

Here is the short rule: keep the work local when the input is private, repeated, easy to do on device, or annoying to reconstruct later. Use an online tool when the input is public, the task depends on remote data, or the web app gives you a clearly better result.

This is not a purity test. I build small Mac apps, so my bias is obvious. I still use online tools when they are the right tool. What I dislike is the default habit of pasting sensitive fragments into whichever formatter ranks first today.

Quick decision table

The privacy test

Ask one question before using a web utility: would I paste this same text into a public GitHub issue? If the answer is no, stop and use a local tool.

JSON payloads are the obvious example. A pretty-printer may feel harmless because the task is mechanical. The content still matters. Payloads often contain names, email addresses, API paths, internal IDs, access scopes, feature flags, tokens, order details, or enough structure to expose how a private system works.

The same applies to colors and images in a different way. A sampled color from unreleased UI can be a design detail you are not ready to publish. A screenshot may include the thing you meant to share plus ten things you forgot to crop out. Local tools reduce that upload decision to zero because no upload happens in the first place.

The repeat-work test

A browser tab is cheap once. It is expensive when the task repeats every day.

If you format JSON once a month, a public online formatter for fake data is acceptable. If you format JSON, decode JWTs, convert timestamps, resize images, pick colors, clean text, and check contrast several times a day, those tabs become a workflow tax. You hunt for the tool, verify the tool, paste the thing, copy the output, and close another tab you did not want.

That is the practical argument for menu bar utilities. A tool that lives one click away can be less impressive on a feature checklist and still win in real use because it removes the search step.

The local-feature test

Some utility jobs are naturally local because macOS already has the APIs. Apple documents NSColorSampler as the AppKit interface for sampling existing onscreen colors. TeenyColor uses that system sampler, converts the result to sRGB, saves it to local history, and copies the selected format to the pasteboard.

Apple's own Digital Color Meter is another local option. It can show the color under the pointer, change RGB display values, adjust aperture size, lock the sample point, and copy a color value as text. It is useful, but it is built as an inspection tool, not as a history-and-reuse workflow.

TeenyTool makes the same local-first argument for text, developer, image, color, PDF, clock, math, and random utilities. Its source currently lists tools such as JSON Formatter, JWT Decoder, Base64 Codec, Regex Tester, YAML to JSON, CSV to JSON, JSON Diff, image resize/compress/convert, EXIF stripping, contrast checking, PDF splitting, and QR code generation. Network-specific tools are the exception, not the pattern.

When online tools are the better choice

Use the web when the job needs the web. DNS lookups, IP geolocation, package metadata, current exchange rates, hosted screenshots, link previews, SERP checks, and product pricing checks all depend on remote data. A local app can provide the panel, but the answer still comes from somewhere else.

Use the web when collaboration is the main point. If your team is reviewing an image together, using a shared Figma file or issue tracker is better than passing local exports around. Local is not automatically better when the workflow is social.

Use the web when the local tool is pretending. A "local" desktop wrapper that ships a remote web view and uploads your input has not solved the privacy problem. The important question is where the work happens, not where the icon lives.

How to choose a local utility

Look for boring claims you can verify. A good local utility should say what runs on device, what uses the network, what permissions it asks for, and what pricing model you are buying.

• Prefer explicit network exceptions. "Everything is private" is vague. "These four tools use the network" is useful.
• Check permissions. A screenshot app needs screen recording. A color sampler may need screen access. A JSON formatter should not need your contacts.
• Favor plain ownership. One-time purchase, free open source, or subscription can all be fair. The problem is surprise.
• Watch for history behavior. Clipboard, color, screenshot, and text utilities should make it clear what they store and how to clear it.
• Use the smallest app that does the job. A launcher, automation suite, or design workstation is useful when you need one. It is too much when you only need one conversion.

Where TeenyApps fits

TeenyTool is the broad local toolbox in the TeenyApps family. It is best for the jobs that used to scatter across browser tabs: JSON formatting, encoding, text cleanup, color utilities, image tools, PDF utilities, date math, timers, and quick generators.

TeenyColor is the focused version of the same idea. It handles one tiny workflow: pick a color anywhere on the Mac, copy it in a useful format, keep a local history, pin important colors, export the palette, and check contrast against black or white.

For the two most common repeat workflows, the deeper guides are offline JSON formatting on Mac and Mac color picker history. If the work is specifically design-to-development handoff, use the Mac design handoff utilities guide for color codes, URL encoding, and copied snippets. If you are setting up a physical workstation, the same rule shows up in the docked Mac desk setup guide: keep private repeat work local, and only add a menu bar app when it removes daily friction. For always-on tools that ask for system access, use the Mac menu bar app permissions guide before approving anything broad.

The bundle approach is not for everyone. If you prefer one large command center, Raycast, Alfred, or another launcher may fit better. The TeenyApps bet is that some jobs deserve small local tools with narrow responsibilities.

Sources checked

• TeenyTool and TeenyColor facts were checked against the local product homepages and source files, including TeenyTool's tool catalog and TeenyColor's picker, history, format, and export code.
• Apple App Sandbox documentation for the macOS sandbox model and explicit resource access.
• Apple NSColorSampler documentation for system color sampling behavior.
• Apple Digital Color Meter User Guide for built-in color inspection and copy behavior.
• RFC 8259 for JSON as a lightweight text data interchange format.
• W3C WCAG contrast guidance for contrast ratio thresholds used in accessibility checks.