15 Best Free Online Developer Tools to Bookmark

Every developer has a bookmark folder full of dead links: tools that added a sign-up wall, started watermarking output, or quietly began uploading files to a server. This is a shortlist of free online developer tools that are worth a permanent slot — what each one solves, when the command line beats it, and how to verify a tool actually runs in your browser before you paste anything sensitive into it.

#TL;DR

• Bookmark tools by the task you repeat, not by how impressive the landing page looks.
• Client-side tools keep your data local; verify with DevTools' Network tab in ten seconds.
• JSON, diff, JWT, hashing and Base64 cover most day-to-day one-off work.
• Image and colour tools in the browser now match desktop apps for routine jobs.
• Free tiers that watermark or rate-limit are upsell funnels — check for a pricing page first.

#What makes a developer tool worth bookmarking

A bookmark is a commitment. You will reach for the tool under pressure, during an incident, with a token or a customer file in your clipboard. Three things decide whether that goes well.

#Does the tool upload my file to a server?

This is the question that matters most and the one almost nobody checks. Server-side tools receive your payload in full. Even with an honest privacy policy, you inherit their logging, their retention window, and their breach surface. A browser-only tool has none of that, because the bytes never leave your machine.

Modern browsers make the local version genuinely practical. FileReader and Blob handle input, WebAssembly handles the heavy lifting, and HTMLCanvasElement.toBlob() re-encodes images — a method MDN lists as Baseline widely available since January 2020. There is no technical reason left for a JSON formatter or an image compressor to need a server.

#How to tell if a web tool runs client-side

Ten seconds, no trust required:

1. Open the tool, then open DevTools → Network.
2. Click the clear button so the log is empty.
3. Paste your input (use dummy data the first time) and run the operation.
4. Watch the log.

A genuine client-side tool records nothing new, or only cached static assets. A server-side tool fires a POST and you can see your own payload in the request body. Try it on the tools below — this is the whole audit.

# The offline equivalent of the same check:
# load the page, kill the network,
# and see if it still works.
curl -s https://ikit.app > /dev/null
# then: DevTools → Network → Offline → run the tool

#Sign-up walls, watermarks, and rate limits

If a tool has a paid tier, the free tier exists to make you want the paid one. That usually shows up as a watermark, a file-count cap, or a daily limit that appears the week you start depending on it. Before bookmarking, look for a /pricing page. No pricing page usually means no upsell mechanic to worry about.

#The data-format tools you'll open every week

These five handle the unglamorous work that fills a developer's day — reading a payload someone pasted into Slack, spotting why two config files differ, moving a spreadsheet into an API.

#Best free JSON formatter and validator online

A minified JSON blob from a log line is unreadable, and JSON.parse in the console gives you an object rather than a diffable document. A JSON decoder that pretty-prints and validates in one pass tells you both what the structure is and exactly which character position is malformed.

The parse error is the valuable part. Node gives you the position; a good browser tool highlights the line:

try {
  JSON.parse(payload);
} catch (e) {
  console.error(e.message);
  // Unexpected token } in JSON at position 214
}

#CSV ↔ JSON without RFC 4180 surprises

CSV looks trivial until a field contains a comma, a quote, or a newline. The format was only ever documented after the fact: RFC 4180, published in October 2005, registers the text/csv media type and describes the common conventions — CRLF line endings, an optional header row — while openly acknowledging that implementations differ. That gap is why a CSV ↔ JSON converter that handles quoting correctly saves more time than it looks like it should.

#Diff checker for comparing two texts

git diff is the right tool inside a repo. Outside one — two API responses, a translated string pair, a config from staging versus production — you need something that takes two pastes. A diff checker with word-level highlighting shows that only one token changed, rather than marking the whole line red.

#Regex tester that matches your runtime

Regex behaviour is not portable. Lookbehind, named groups, and Unicode property escapes differ between JavaScript, PCRE and Python, so a pattern verified in the wrong dialect fails in production. A regex tester running the same JavaScript engine as your browser gives you an answer you can trust for front-end and Node code.

Sooner or later something also hands you a SOAP envelope or a .sql dump. An XML formatter and a SQL-to-Excel converter are rarely-used-but-load-bearing bookmarks: you need them twice a year and you need them immediately.

#Encoding, tokens, and identifiers

#How to decode a JWT without pasting it into a website

A JWT is three Base64url segments joined by dots. The header and payload are encoded, not encrypted — anyone holding the token can read them. That is exactly why the decoding should happen locally: a production token pasted into a server-side decoder is a credential sent to a third party.

const b64url = (s) =>
  s.replace(/-/g, "+").replace(/_/g, "/");

const [header, payload] = token
  .split(".")
  .slice(0, 2)
  .map((p) => JSON.parse(atob(b64url(p))));

console.log(payload.exp); // 1790000000

That exp value is Unix seconds, which is where a timestamp converter earns its bookmark during a 401 debugging session.

#Base64 and URL encoding: which one do I need?

They solve different problems and are constantly confused. Base64 makes binary data survive a text-only channel. Percent-encoding makes characters survive a URL's own syntax. A string can need both, in that order, and getting the order wrong produces the double-encoded %2520 you see in broken redirect chains. An HTML encoder covers the third case — escaping for markup rather than transport.

#How to generate a UUID v4 in the browser

RFC 9562, published in May 2024, replaced RFC 4122 as the UUID specification and added the time-ordered v7 format alongside the familiar random v4. For v4 you do not need a library at all:

crypto.randomUUID();
// "1f0a2b3c-4d5e-4f60-8a1b-2c3d4e5f6071"

Use a UUID generator when you want a batch of them to paste into fixtures, and crypto.randomUUID() when you're writing code.

#Security tools where the source of randomness matters

#Why you should never use Math.random() for passwords

Math.random() is a fast, non-cryptographic PRNG. Its internal state is small and its output is predictable to an attacker who has seen enough of it — which makes it fine for shuffling an array and disqualifying for anything an attacker would want to guess.

The Web Crypto API is the correct source. MDN notes that Crypto.getRandomValues() has been available across browsers since July 2015, and that while the specification mandates no minimum entropy, implementations are expected to seed from a platform source such as /dev/urandom. There is one sharp edge worth knowing: requesting more than 65,536 bytes in a single call throws QuotaExceededError.

A password generator built on getRandomValues() produces secrets that are safe to use. One built on Math.random() produces theatre. You cannot tell them apart from the output, which is the argument for using a tool whose implementation you can read.

#Hash generator for MD5, SHA-1, SHA-256 checksums

Verifying a downloaded artifact against its published checksum is a 30-second habit that catches both corruption and tampering. A hash generator covering MD5, SHA-1, SHA-256/384/512 and CRC32 handles the full range of what projects publish — including the legacy algorithms you still encounter and should not trust for security decisions.

#Image and design tools that replace a Photoshop round-trip

#How to compress images without uploading them

Canvas re-encoding is the whole trick. The browser decodes your image, draws it to a canvas, and re-encodes it at a chosen quality — toBlob() takes a quality value between 0 and 1 for lossy formats like JPEG and WebP, and defaults to PNG when the requested type isn't supported. An image compressor that batches this across files and zips the result covers the everyday case completely.

Two side effects are worth knowing. Re-encoding drops EXIF metadata, which removes GPS coordinates from photos before you publish them. And it is lossy — compressing an already-compressed JPEG degrades it further, so always work from the original.

The rest of the image set follows the same pattern: an image format converter, a resizer with social presets, a cropper, an app icon generator that emits every iOS/Android/web size at once, and a background remover that runs its model in WebAssembly rather than on someone's GPU cluster.

#Colour tools: picker, palette, gradient

CSS Color Module Level 4 brought oklch() into mainstream use, and perceptually uniform colour changes what a palette tool can do — lightness steps that look even actually are even. A colour picker and converter, a palette generator and a gradient generator together cover the design-token work most developers do without opening a design app.

#Writing, time, and the long tail

#Markdown editor, word counter, lorem ipsum

The Markdown editor is the one to bookmark first if you write READMEs. GitHub Flavored Markdown is a strict superset of CommonMark — whose current spec, version 0.31.2, dates from January 2024 — so a GFM-accurate live preview is the difference between shipping a README and fixing it after the fact. Add a word counter for anything with a length limit and a lorem ipsum generator for layout work.

#Timestamps, timers, and QR codes

A Unix timestamp converter for logs and token claims, a countdown timer and stopwatch for anything time-boxed, and a QR code generator for Wi-Fi credentials, vCards and URLs. Individually minor; collectively they are half the reason the folder exists.

#The bookmark bar setup that actually sticks

• One folder, named for the task ("tools"), not the vendor.
• Order by frequency, not alphabetically — the top three get 80% of the clicks.
• Assign a keyword shortcut in Chrome or Firefox so the tool is two keystrokes away.
• Prune every six months: any bookmark you haven't opened in that window is dead weight.
• Prefer tools with stable URLs that encode state, so a bookmark can carry your settings.

All 33 tools on iKit follow the same rule — the page loads, the work happens locally, and nothing is uploaded. That includes the PDF suite, which packs 26 sub-tools (merge, split, compress, OCR, sign, encrypt) behind a single bookmark.

#References

• Crypto: getRandomValues() method — MDN — Baseline availability, entropy sourcing, and the 65,536-byte QuotaExceededError limit.
• HTMLCanvasElement: toBlob() method — MDN — canvas re-encoding, the quality parameter, and default PNG behaviour.
• RFC 9562 — Universally Unique IDentifiers (UUIDs) — publication date and its replacement of RFC 4122.
• RFC 4180 — Common Format and MIME Type for Comma-Separated Values (CSV) Files — text/csv registration and the documented CSV conventions.
• CommonMark Spec — current spec version and date, used for the GFM superset note.

#Related on iKit

• Why I built iKit: 14 privacy-first tools that stay in your browser — the reasoning behind making every tool client-side, from the person who wrote them.
• How iKit runs entirely in your browser — a technical deep-dive — the APIs and WebAssembly modules that make server-free processing possible.
• The architecture behind 14 client-side tools — how the suite is structured, and why each tool ships as an independent deployment.