DEV Community

Collabier
Collabier

Posted on

Why I stopped pasting sensitive data into random developer tools

I probably don't need to explain how often developers use online utility websites.

Need to decode a JWT? Search Google.

Need to format some ugly JSON? Search Google.

Need to convert an image, calculate a subnet, generate a regex, or inspect a timestamp? Search Google again.

I've done this for years.

The problem is that eventually you stop thinking about what you're actually pasting into those websites.

A JWT might contain information that shouldn't be shared. An API response might contain customer data. A configuration file might contain internal URLs. A PDF might contain confidential information.

And yet the workflow is usually:

Copy → Paste → Get the result → Close the tab.

That bothered me enough that I started building my own collection of browser-based tools.

The thing that changed my mind

A while ago I was debugging an authentication problem.

I had a token in my clipboard and was about to paste it into one of the many JWT decoder websites I had bookmarked.

Then I stopped.

I opened DevTools first.

It made me think about something that I usually ignore: where does the data go after I paste it?

Obviously, not every online utility is doing something malicious. Some are perfectly legitimate and have good privacy policies.

But I realized that I didn't actually need a server for many of the tasks I was performing.

Modern browsers are surprisingly capable.

JavaScript can handle JSON parsing, hashing, image processing, file manipulation, encoding/decoding, and plenty of other operations directly on the user's machine.

So why send the data anywhere in the first place?

Building my own toolbox

That idea eventually became Omnikite.

The goal wasn't to build another huge SaaS platform.

I wanted something closer to a developer's toolbox:

  • Open a tool
  • Do the job
  • Copy the result
  • Close it

No account required for basic utilities.

No unnecessary dashboard.

No complicated workflow.

Just tools.

Some of the tools

I started with the things I personally use most often.

JSON

One of the first tools was a JSON Formatter & Validator.

This is probably one of the most boring developer tools on the internet, but I use it constantly.

The useful part isn't formatting JSON. That's easy.

The useful part is making it comfortable to work with large payloads, search through nested objects, validate syntax, and generate useful representations such as TypeScript types.

JWT debugging

Another one is an online JWT debugger.

Instead of sending a token somewhere just to inspect its header and payload, the browser can decode the token locally.

For cryptographic operations, browser APIs such as SubtleCrypto can also handle algorithms such as SHA-256 and HMAC.

One important distinction here:

Decoding a JWT is not the same thing as verifying its signature.

A JWT payload is encoded, not encrypted.

That's an easy detail to forget when you're debugging authentication.

IP and subnet calculations

I also built an IPv4 subnet calculator.

This started as a small utility because I kept looking up CIDR calculations while working with APIs, servers, and network configurations.

Eventually it became more useful than I expected.

Seeing the binary representation of the address makes subnet calculations much easier to understand than simply getting an answer like:

192.168.1.0/24
Enter fullscreen mode Exit fullscreen mode

Security utilities

There are also several security-related utilities.

For example:

Shamir's Secret Sharing

It's a useful concept when you need to split a secret into multiple shares where a predefined number of shares are required to reconstruct it.

I also added an entropy analyzer for looking at password randomness and estimated entropy.

These aren't replacements for proper security tooling, but they're handy for quick experimentation and understanding.

Browser APIs are doing more work than people realize

One of the interesting parts of building this project has been realizing how much can be done without a backend.

For example, calculating a SHA-256 hash doesn't require an npm package or API endpoint.

The browser already provides the functionality:

async function sha256(value: string): Promise<string> {
  const data = new TextEncoder().encode(value);

  const hash = await crypto.subtle.digest("SHA-256", data);

  return Array.from(new Uint8Array(hash))
    .map(byte => byte.toString(16).padStart(2, "0"))
    .join("");
}
Enter fullscreen mode Exit fullscreen mode

That's it.

The data goes into the browser's Web Crypto API and the resulting hash comes back.

No HTTP request is necessary for that operation.

That's the approach I'm trying to follow throughout the project whenever the operation can reasonably be performed locally.

Files are another interesting case

File processing gets a little more complicated.

PDFs, images, archives, and other binary formats can require considerably more processing than a simple string operation.

But even here, there are browser technologies that make local processing possible.

Depending on the format and operation, you can use:

  • Web Workers
  • WebAssembly
  • Canvas
  • File APIs
  • Streams
  • IndexedDB
  • Web Crypto

For example, the PDF tools are designed around browser-side processing rather than automatically uploading documents to a server.

That's particularly useful for documents you don't want leaving your computer.

Of course, I still recommend checking the actual implementation and privacy behavior of any tool before putting genuinely sensitive information into it.

The stack

The project is built with technologies that I already use regularly:

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Web APIs
  • Web Crypto
  • Web Workers
  • WebAssembly where appropriate

One thing I intentionally avoided was creating a backend for every tiny operation.

If the browser can safely perform a task, I'd rather let the browser do it.

That also has another nice side effect: less infrastructure.

Less server code means fewer things to deploy, monitor, scale, and maintain.

I'm still adding tools

The interesting part about a toolbox project is that there is almost no shortage of things to add.

There are always those tiny utilities that developers search for repeatedly:

  • UUID generators
  • Regex testers
  • Cron expression helpers
  • Timestamp converters
  • Base64 tools
  • URL encoders
  • Color converters
  • Markdown utilities
  • Hash generators
  • SQL formatters
  • CSS generators
  • Image converters
  • PDF utilities
  • Text comparison tools

Some are trivial to build.

Some aren't.

And some look trivial until you start thinking about edge cases.

That's actually been one of the more enjoyable parts of the project.

One thing I'm trying to avoid

I don't want this to become another website where every tool is surrounded by five advertisements, three popups, and a newsletter form.

When I'm looking for a JSON formatter, I want a JSON formatter.

Not a 2,000-word article before the textarea.

Not a signup flow.

Not a notification asking me to download an app.

Just the tool.

That's the experience I'm trying to build with Omnikite.

It's still a work in progress, but I'm gradually adding more utilities and improving the existing ones.

If you work with APIs, frontend development, networking, security, or just spend too much time searching Google for tiny utilities, you might find something useful there.

Browse the Omnikite tools

And if you have a small developer utility that you use all the time, I'd genuinely like to know what it is.

Those are usually the best tools to build next.

Top comments (0)