DEV Community: FindUtils

Cookie-Free Analytics Explained: How Privacy-Friendly Analytics Count Visitors Without Cookies

FindUtils — Wed, 14 Oct 2026 12:34:54 +0000

For years, “counting visitors” meant dropping a cookie (or three), stitching sessions across days, and hoping the consent banner was enough. A growing set of products take a different path: measure traffic with no cookie on the visitor by default, keep reports at the aggregate level, and treat person-level profiles as an explicit opt-in — not the starting point.

This piece has two layers. First, the general technique behind cookieless / privacy-friendly analytics (industry knowledge — not unique to any one vendor). Second, what DataVisitors documents about its own approach on its privacy, how-it-works, and product pages. Those two layers stay separate on purpose.

Important: DataVisitors is waitlist-only right now. Accounts open by invitation. There is no “start a free trial” or “create an account now” path on the public site — join the waitlist, confirm the email, and wait for a seat. You can explore the live demo without an account.

Nothing in this article is legal advice. Cookie banners, consent, and ePrivacy rules depend on your jurisdiction, your other trackers, and how you configure the product. Talk to counsel for compliance decisions.

Why cookies became the default (and why people want out)

Classic web analytics often:

Sets a first-party cookie with a stable visitor ID.
Reuses that ID across days and sometimes across subdomains.
Builds funnels, retention, and “who is this person?” views from that ID.

That model is powerful. It is also exactly what many privacy laws and browser features push against: persistent identifiers on the device, cross-context tracking, and opaque third-party beacons. Cookieless analytics try to answer a narrower question well — how many visits, from where, to which pages, completing which goals — without needing a durable ID in the browser.

The general technique: daily salted hashes (illustrative)

A common cookieless pattern looks like this (simplified; illustrative, not a claim that any specific product uses this exact code):

// ILLUSTRATIVE ONLY — not DataVisitors source code
import crypto from 'node:crypto';

function dailyVisitorKey({ ip, userAgent, projectId, utcDate, dailySalt }) {
  // Salt rotates once per UTC day; projectId keeps sites from sharing IDs
  const material = [utcDate, dailySalt, projectId, ip, userAgent].join('|');
  return crypto.createHash('sha256').update(material).digest('hex');
}

// Count uniques inside one UTC day by inserting the key into a set/HLL

What this buys you:

Same person, same day, same site → same key → counts once toward daily uniques.
Next UTC day → new salt → new key → you cannot stitch a continuous multi-day journey from the identifier alone.
Same person on two projects → different projectId in the hash → two numbers, not one cross-site profile.

Trade-offs (general industry knowledge):

You gain	You usually lose
No cookie required for basic counting	Reliable cross-day “unique visitors” as one person
Harder to build a stalking-style profile from the analytics ID	Some retention / returning-user charts unless another consented ID exists
Smaller consent surface for analytics-only setups (still context-dependent)	Perfect bot resistance from the ID alone

A rotating identifier is not a guarantee that all data is anonymous. IP addresses, referrers, and rare page paths can still be identifying in combination. Privacy-friendly products typically also drop or coarsen fields (e.g. country instead of precise location) and keep public share links at aggregate totals only.

What DataVisitors says it does

The following is taken from DataVisitors’ own pages — privacy approach, how it works, FAQ, web analytics, and integrations.

No cookie on a visitor (by default)

The privacy page states: “The tracking script sets no cookie. It starts stateless.” The FAQ repeats that the tracker starts stateless and that whether device storage is ever used depends on the project’s privacy regime and the visitor’s consent.

A daily, project-scoped identifier

Privacy approach: a visit is counted with “the day’s salt, minted once per UTC day.” The stored sample record describes the visitor as a “daily-salted hash, project-scoped.” Explicitly: “One person on two sites is two numbers” because the project is inside the hash — visitors cannot be joined across sites via that identifier.

FAQ phrasing: “Stateless measurement uses a daily identifier that differs between projects. Device storage depends on the project's privacy mode and the visitor's consent. A rotating identifier does not guarantee that all data is anonymous.” That last sentence is worth quoting in full — it matches the honest industry caveat above.

Privacy regimes you choose per project

DataVisitors documents three regimes (privacy approach):

Automatic (default): Stateless where the law is strict; device storage elsewhere when allowed.
Strict: Nothing stored on the device anywhere until your site’s consent allows it; until then every visit uses the daily salt only.
Relaxed (opt-out): A first-party id may be kept on the device by default; Global Privacy Control, Do Not Track, and an opt-out call are honoured.

The page also says Global Privacy Control and Do Not Track are respected in all regimes; only an explicit consent from your own banner outranks them. In the EEA, UK, Switzerland, or an unresolved country, nothing is stored on the device until your site’s consent allows it (Automatic / Strict behaviour as documented).

Aggregates first; People off by default

Public share links show aggregates only, never an individual visitor. The People feature stays closed until an administrator opens it, and switching it on is recorded. Exports, erasure, and account closure are described as available on every plan — erasure removes a person’s events and traits and keeps a hashed tombstone.

What you can measure (web analytics)

The web analytics feature page describes visitors, page views, sessions, sources (referrer / channel / UTM), pages, engagement (bounce, duration, scroll depth), goals, bot/referrer-spam filtering, and an AI assistants channel for recognized referrers such as ChatGPT, Claude, Perplexity, Gemini, and Copilot. It also clarifies visitor vs session vs page view, and warns that dual-counting page views from both browser and server will inflate totals.

How you connect it (when invited)

How it works and the browser integration document a deferred snippet shaped like:

<script
  defer
  src="https://api.datavisitors.com/assets/sg.js"
  data-key="YOUR-INSTALL-KEY"
></script>

Set allowed origins and privacy settings before the first event. Use one source for page views (browser or server, not both for the same load). Server-side and webhook events go through the HTTP API with separate ingest and read keys.

Pricing context (no “start now”)

Pricing lists Free / Starter / Growth / Business with event ceilings and feature gates, but prices are marked “not published yet.” Every plan CTA is Join the waitlist. Past an events ceiling, the site says collection continues; the plan gates reading. That is product documentation, not an invitation to sign up today.

How this compares to “just turn off cookies in GA”

Flipping a cookieless flag in a cookie-first product is not the same architecture as designing aggregates + daily salts from day one. Cookie-first tools often still lean on device storage when allowed, and their mental model remains “user ID → journey.” Privacy-first tools push you toward questions the aggregate can answer: which sources convert, which pages bounce, whether a release moved the needle — and they make person-level data a deliberate switch.

If you also run free browser-only utilities for day-to-day debugging (headers, JSON, PDF chores), that is a separate trust story from analytics — FindUtils keeps those tools client-side. Analytics still needs a server somewhere to store counts; the privacy question is what you store and how you identify a visit.

Practical checklist if you are evaluating cookieless analytics

Read the privacy page, not only the homepage. Look for: cookies or not, salt rotation period, cross-site joining, consent behaviour, GPC/DNT.
Decide your regime before the first event. Changing later does not rewrite history the way you might hope.
One page-view source. Dual instrumentation doubles page views.
Goals over vanity uniques. A signup goal survives cookieless limits better than “users this month” marketing slides.
Ask what public links expose. Aggregate-only share URLs are a strong signal.
For DataVisitors specifically: explore the demo, read privacy and FAQ, then join the waitlist. Do not expect a self-serve signup today.

Wrap-up

Cookie-free analytics usually means: no cookie by default, a short-lived or salted identifier for same-day counting, project scoping so IDs do not federate across sites, and aggregates as the default report. DataVisitors documents exactly that pattern — daily-salted, project-scoped hashes; three privacy regimes; People off until an admin enables it; waitlist-gated accounts.

Start at datavisitors.com, dig into the privacy approach and how it works, try the demo, and join the waitlist if you want a seat when invitations open.

Add an Emoji Favicon with One Line of HTML (Next.js, Astro, Vue, WordPress) Plus Dynamic Tab Notifications

FindUtils — Wed, 14 Oct 2026 12:34:11 +0000

Favicons used to mean a ZIP of PNGs, an ICO, an apple-touch icon, and a half-remembered manifest.json. For a lot of sites, that is still the right approach. For many others — a side project, a docs site, a staging deploy, a dashboard that needs a notification badge — you only need one emoji in the tab, and you need it today.

EmojiFavicons is a URL-based emoji favicon service from FindUtils. You point a normal <link rel="icon"> at an emoji slug, and the API returns an SVG (under 200 bytes for a plain emoji, per the docs). No signup, no API key, no build step. This article sticks to what the site documents and what the endpoints actually return when you request them.

The one-line install

Drop this in your HTML <head>:

<link rel="icon" href="https://emojifavicons.com/fire">

Replace fire with any emoji name. The homepage and docs state that EmojiFavicons covers 3,773 Unicode emojis, searchable by 11,550 keywords. Names and keywords are case-insensitive. You can also use a keyword (/hot resolves to fire), a URL-encoded emoji character, or a country code for flags (/US, /TR).

A live request to https://emojifavicons.com/fire returns image/svg+xml — a tiny SVG wrapping the 🔥 glyph. Safari is a special case: the how-it-works page explains that Safari has limited SVG favicon support, so the service auto-serves a PNG (Twemoji) for Safari User-Agents. You can force a format with ?svg or ?png.

If you later want a classic downloadable package instead of a live URL, the docs also expose GET /download/:emoji — for example https://emojifavicons.com/download/rocket returns a ZIP of standard sizes. That is the honest self-host path when you do not want a third-party dependency at runtime.

Customize with URL parameters

Every favicon endpoint accepts query parameters. A documented example that works today:

https://emojifavicons.com/fire?size=64&bg=1a1a1a&animate=pulse

That request returns image/svg+xml with a 64×64 viewBox, a dark background, and a CSS pulse animation. Useful parameters from the docs (not an exhaustive list):

Parameter	What it does (per docs)
`size`	SVG size in pixels (16–512; default 48)
`bg`	Background hex without `#`
`shape`	e.g. `circle`, `rounded`, `hexagon`, …
`animate`	e.g. `pulse`, `bounce`, `spin`, and many others
`badge`	Notification overlay: `1`–`99` or `dot`
`theme`	Branded presets such as `github-dark`, `vercel-dark`, `tailwind`
`png` / `svg`	Force output format

Combine freely. Combos put 2–10 emojis side by side with a +:

<link rel="icon" href="https://emojifavicons.com/fire+rocket">

That endpoint returns a single SVG with 🔥 and 🚀 next to each other — useful for “shipping fast” vibes without designing an icon.

For a red unread count without JavaScript:

<link rel="icon" href="https://emojifavicons.com/bell?badge=3">

Framework installs (verified against the official guides)

The frameworks index lists 19 tutorials. Below are the four most common, copied from the site’s own guides. In every case, remove or rename any default favicon.ico / favicon.svg in public/ so the external URL wins.

Next.js (App Router)

From the Next.js guide:

// app/layout.tsx
import type { Metadata } from 'next';

export const metadata: Metadata = {
  icons: {
    icon: 'https://emojifavicons.com/rocket',
    apple: 'https://emojifavicons.com/apple-touch-icon/rocket',
  },
};

Pages Router: put the <link> tags in pages/_document.tsx inside <Head>. The guide notes that Vercel may cache an old favicon for up to 24 hours; append ?v=2 if you need a cache bust.

Astro

From the Astro guide, in your shared layout:

<head>
  <link rel="icon" type="image/svg+xml" href="https://emojifavicons.com/rocket" />
  <link rel="apple-touch-icon" href="https://emojifavicons.com/apple-touch-icon/rocket" />
</head>

Delete public/favicon.svg if the starter left one. Keep the tags in the persistent layout so View Transitions do not thrash the tab icon.

Vue 3 + Vite / Nuxt 3

From the Vue guide:

Vite: edit root index.html:

<link rel="icon" type="image/svg+xml" href="https://emojifavicons.com/rocket" />
<link rel="apple-touch-icon" href="https://emojifavicons.com/apple-touch-icon/rocket" />

Nuxt 3: in nuxt.config.ts:

export default defineNuxtConfig({
  app: {
    head: {
      link: [
        { rel: 'icon', type: 'image/svg+xml', href: 'https://emojifavicons.com/rocket' },
        { rel: 'apple-touch-icon', href: 'https://emojifavicons.com/apple-touch-icon/rocket' },
      ],
    },
  },
});

WordPress

From the WordPress guide, append to the child theme’s functions.php (or a site-wide snippets plugin):

add_action('wp_head', function () {
  echo '<link rel="icon" href="https://emojifavicons.com/rocket" type="image/svg+xml">';
  echo '<link rel="apple-touch-icon" href="https://emojifavicons.com/apple-touch-icon/rocket">';
});

Clear the Customizer Site Icon if WordPress still serves its own. Hard-refresh after saving.

Dynamic tab notifications with the JS SDK

Static badges are fine for marketing sites. Apps need the tab to react. Include the SDK once:

<script src="https://emojifavicons.com/sdk.js"></script>

https://emojifavicons.com/sdk.js returns application/javascript. The homepage and docs show the core surface; the script itself exposes:

EmojiFavicon.set('rocket');
EmojiFavicon.animate('fire', 'pulse');
EmojiFavicon.notify('bell', 3000); // flash, then restore
EmojiFavicon.restore();
EmojiFavicon.setBadge('bell', 5);
EmojiFavicon.clearBadge();

A practical pattern for “you have new messages while the tab is in the background”:

function onUnread(count) {
  if (count > 0) {
    EmojiFavicon.set('bell', { badge: Math.min(count, 99) });
  } else {
    EmojiFavicon.restore();
  }
}

notify(emoji, durationMs) temporarily swaps the icon, then restores the previous href — handy for a one-shot alert without managing state yourself.

Trade-offs (be honest)

Depends on a third-party URL. If emojifavicons.com is unreachable, the tab falls back to whatever the browser does without a favicon. The compare page itself lists this as a con of URL-based services, mitigated by CDN caching (docs: 7-day CDN cache, 24-hour browser cache) and by downloading the SVG/PNG/ICO (or the ZIP from /download/:emoji) and hosting it yourself.

Rate limits. The FAQ on the homepage says normal use has a 300 requests per minute limit, with no signup or credit card required. That is generous for a favicon, but it is still a shared free resource — do not hammer it from a CI loop that rebuilds thousands of pages per minute.

Not a full custom-image favicon studio. If you need a hand-drawn mark or a photo crop, generate and self-host assets instead. For that workflow, FindUtils’ favicon generator is a useful browser-side companion when you already have an image file. EmojiFavicons and the FindUtils generator solve different problems: emoji-as-URL vs. image-to-package.

Caching surprises. CDNs and browsers cache favicons aggressively. After a change, hard-refresh or bump a query string.

Quick health check

Before you ship, run your domain through the Favicon Health Checker. It scores icon / SVG / apple-touch / manifest coverage and offers copy-paste fixes. Pair that with the interactive generator if you want to preview size, shape, animation, and badge before pasting a URL into production.

Wrap-up

Add <link rel="icon" href="https://emojifavicons.com/fire"> (or your emoji of choice).
Optionally tune with ?size=, ?bg=, ?animate=, ?badge=, or a combo like /fire+rocket.
Follow the framework guide for Next.js, Astro, Vue, or WordPress.
For runtime swaps, load sdk.js and call set / animate / notify.
If you outgrow a third-party URL, download the ZIP and self-host.

Start at emojifavicons.com, browse the docs, and if you need more free browser-only utilities beyond favicons, FindUtils has a large catalog of client-side tools that never upload your files.

Why Is My Email Going to Spam? A Browser-Only Triage for SPF, DKIM, DMARC, PTR and Blocklists

FindUtils — Wed, 14 Oct 2026 08:52:54 +0000

Few things are as quietly maddening as a perfectly normal email landing in someone's spam folder. A password reset, an invoice, a reply to a customer: gone, filed next to fake lottery wins. The good news is that most deliverability problems come down to a small set of DNS records and reputation signals, and you can check nearly all of them from a browser in about fifteen minutes.

This guide walks through the triage in the order I'd actually do it. No terminal, no paid dashboards. Just evidence first, then fixes.

Step 0: Get one real message that went to spam

Don't start by guessing at DNS. Start with a message that actually failed. Ask the recipient to forward it as an attachment, or send a test to a Gmail or Outlook account you control and find it in Junk.

Then open the full headers ("Show original" in Gmail, "View message source" in Outlook). This raw text is the single most useful thing you'll look at today, because it contains the receiving server's own verdict.

Step 1: Read the headers before touching anything

Paste the raw headers into the Email Header Analyzer. It traces the routing path hop by hop, lists the IP address of each server along the way, and pulls out the SPF, DKIM and DMARC results.

Look for the Authentication-Results line. You'll typically see something like spf=pass, dkim=fail, dmarc=fail. That tells you where to dig:

All three pass, still spam? The problem is probably reputation or content, not authentication. Skip ahead to Steps 5 and 6.
SPF fails: the sending IP isn't authorized for your domain.
DKIM fails or is missing: the message wasn't signed, or the signature doesn't match the published key.
DMARC fails: neither SPF nor DKIM passed in alignment with the From domain (more on that below).

Also write down the IP of the first external hop, the server that actually handed the mail to the internet. You'll need it for the PTR and blocklist checks.

Step 2: Check SPF

What it is: SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers are allowed to send mail for it. It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Run your domain through the Email Security Checker, which inspects SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI in one pass. If you want to see the raw records yourself, the DNS Lookup tool will show every TXT record on the domain.

Common SPF mistakes:

Two SPF records. You're allowed exactly one TXT record starting with v=spf1. Adding a second one when you sign up for a new service is the most common way people break SPF. Merge them into one.
Too many lookups. SPF has a limit of 10 DNS lookups (each include, a, mx and redirect counts, and nested includes count too). Go over and receivers return a permerror, which often behaves like a fail.
Forgetting a sender. Your newsletter tool, your CRM, your helpdesk, the billing system: every service that sends as your domain needs to be covered, or needs to send from a subdomain with its own record.
Using +all. This authorizes the entire internet. Never do it. Use ~all (soft fail) while testing and -all once you're confident.

Step 3: Check DKIM

What it is: DKIM adds a cryptographic signature to each message. The receiving server fetches your public key from DNS at selector._domainkey.yourdomain.com and verifies the signature.

The selector is in the DKIM-Signature header of your message (the s= value). Look up that exact name as a TXT record with DNS Lookup, or let the Email Security Checker find it.

Common DKIM mistakes:

Signing is never turned on. Many providers require you to publish the key and click an "enable" or "authenticate" button. Publishing the record alone does nothing.
Broken key formatting. Long keys are sometimes split into multiple strings, and some DNS panels add stray quotes or line breaks. A single missing character invalidates the key.
Signing with the provider's domain. If the signature says d=mailprovider.net instead of d=yourdomain.com, DKIM may "pass" but won't align for DMARC.

Step 4: Check DMARC

What it is: DMARC is a TXT record at _dmarc.yourdomain.com that tells receivers what to do when a message fails authentication, and where to send reports:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The key idea is alignment. DMARC passes only if SPF or DKIM passes and the domain they validated matches the domain in the visible From address. This is why a message can show spf=pass and still fail DMARC: SPF validated your email provider's bounce domain, not yours.

Common DMARC mistakes:

No record at all. Major mailbox providers now expect bulk senders to have DMARC. Even p=none is better than nothing.
Jumping straight to p=reject. If you haven't confirmed every legitimate sender aligns, you'll block your own mail. Start at none, read the reports, move to quarantine, then reject.
Reports going nowhere. A rua address that no one reads means you're flying blind.

For a broader look at your domain's email-related DNS (MX, SPF, DKIM, DMARC together), the DNS Security Scanner gives a useful second opinion.

Step 5: Check reverse DNS (PTR)

What it is: A PTR record maps an IP address back to a hostname. Receiving servers check that your sending IP has one, and ideally that the hostname resolves back to the same IP (forward-confirmed reverse DNS).

Take the sending IP from Step 1 and run it through the Reverse DNS Lookup.

If you use Google Workspace, Microsoft 365, or a major sending service, PTR is their job, and it's almost always fine.
If you run your own mail server or send from a VPS, a missing or generic PTR (something like 123-45-67-89.static.isp.net) is a classic spam trigger. PTR records are set by whoever owns the IP block, so you'll usually configure it in your hosting provider's panel, not your DNS provider's.

Step 6: Check blocklists

If authentication passes and PTR looks right, reputation is the next suspect. Put the sending IP into the IP Blacklist Checker, which queries five DNS-based blocklists (Barracuda, SpamCop, UCEPROTECT, JustSpam and PSBL) in one go.

Be honest with yourself about the results:

On a shared sending service? A listing on a shared IP is the provider's problem to solve. Open a ticket with them.
On your own server? Find out why before requesting delisting. A compromised account, an open form that sends mail, or a purchased list will get you relisted within days.
Clean everywhere and still in spam? Five lists aren't the whole picture. Big providers like Gmail and Microsoft keep their own internal reputation data, and content, engagement and sending volume all matter. Check their postmaster tools for your domain.

Step 7: Re-check after you change DNS

DNS changes aren't instant. After editing a record, use the DNS Propagation Checker to confirm resolvers around the world see the new value before you conclude a fix "didn't work." Then send a fresh test message and read the headers again. That's the only verdict that really counts.

The quick checklist

[ ] Got the raw headers from a real message that went to spam
[ ] Read Authentication-Results: which of SPF, DKIM, DMARC failed?
[ ] Exactly one SPF record, under 10 lookups, covering every sender, ending in ~all or -all
[ ] DKIM enabled at every sending service, signing with your domain (d=yourdomain.com)
[ ] DMARC record exists at _dmarc, with a rua address someone actually reads
[ ] SPF or DKIM aligns with the From domain
[ ] Sending IP has a PTR that resolves back to the same IP
[ ] Sending IP isn't on any blocklist (and you know why if it was)
[ ] DNS changes have propagated before you re-test
[ ] Sent a fresh test and confirmed the new headers say pass

A final word

Deliverability problems feel mysterious, but they rarely are. In most cases the headers tell you exactly what failed, and the fix is a single DNS record: a duplicate SPF entry, a DKIM key that never got enabled, a missing DMARC policy. Work through it in order, change one thing at a time, and verify with a real message after each change.

All the tools linked above are part of FindUtils, a collection of 463 free tools that run in your browser. No sign-up, no installs.

JSON, PDF and Image Chores in the Browser: A No-Upload Workflow Guide

FindUtils — Tue, 13 Oct 2026 06:40:24 +0000

Most of my "five-minute tasks" are not coding. They are chores: an API response that won't parse, a contract that has to go out as one PDF, a batch of iPhone photos a client can't open. The usual fix is to search for "json formatter online", click the first result, and paste in something you shouldn't.

I built FindUtils partly because of that habit. It is a free toolbox of single-purpose browser tools: 463 at the time of writing. The core tools need no account and no install. This post is less about the site and more about a workflow: how to get through common JSON, PDF and image chores without handing your files to a stranger's server, and how to check that claim for any tool, including mine.

First, how do you know a tool doesn't upload?

"Runs in your browser" is a claim, so test it before you trust it:

Open DevTools → Network before you drop the file in. Clear the log, run the tool, and look for a request whose size matches your file. A client-side tool may still load scripts, fonts, analytics or ads, but none of those requests should carry your data.
Read the page's own data note. A good tool says what leaves the device. On FindUtils, file tools that run locally say so on the page. Lookup tools (DNS, WHOIS, SSL) send the domain you type to the service named on the page, because there's no other way to do a lookup.
Remember what local processing doesn't cover. You still have to trust the page's code, your browser extensions and your device. Client-side is a smaller trust surface, not zero trust.

With that settled, here's the workflow.

JSON: from "invalid" to typed code

1. Fix and read it: JSON Formatter
Paste the payload. The error message gives you the line and column. Auto-Fix makes a conservative repair of the three usual suspects: trailing commas, single quotes and unquoted keys. Format pretty-prints with 2, 4 or 8 spaces, Minify compacts it, and Tree gives you a collapsible view for deeply nested responses. On the page, the JSON is processed in your browser.

2. Compare two versions: JSON Diff
When staging and production return "the same" response but something breaks, a line diff of pretty-printed JSON is noisy. The default view lists semantic paths (added, removed, modified), so user.address.zip showing as modified tells you more than 40 red and green lines. You can switch to a unified, git-style view when you need it.

3. Turn it into types: JSON to TypeScript
Paste a real response and get interfaces or type aliases. It's a better starting point than typing the shape by hand, but review optional fields. A sample can't tell you which keys are sometimes missing. There are siblings for Zod, Go structs and Python classes.

4. Hand it to a spreadsheet person: JSON ↔ CSV
Both directions work on one page, with nested objects, quoted commas and custom delimiters handled. One caution: CSV has no types. "00123" and 123 look the same once they're in a cell, so don't round-trip JSON through CSV and expect the original back.

Bonus: JWT Decoder. A JWT is often a live credential, so pasting one into a random decoder is a real risk. This one decodes and verifies HS256/384/512 and RS256 (with a PEM key) in the browser, and the page states that secrets stay on the page.

PDF: merge, number, clean, in that order

The order matters more than the tools.

1. Merge the files and drag them into sequence. The merge runs in the browser with the open-source pdf-lib library. If you only need part of a document, run Split first.

2. Add page numbers after merging. If you number each file first, you get "1, 2, 3, 1, 2" in the final document. One numbering pass on the merged file gives one sequence.

3. Compress if the file is too big for email. Low rewrites the structure, Medium re-encodes embedded JPEGs, and High also scales them down, so photos may look softer. Text stays the same.

4. Remove metadata as the very last step. A PDF can carry the author's account name, the program that made it and timestamps. The tool shows the Info fields and XMP data and gives you a copy without the ones you tick. Two honest caveats from the tool's own docs: it is a metadata remover, not a forensic scrub (annotation author names and EXIF inside embedded photos stay), and if you open and re-save the cleaned file in another program, that program writes its own Producer and dates back in. So clean last, then send.

If the file must be locked, PDF Protect adds a password with AES-256 encryption.

Images: convert, resize, then compress

1. HEIC to JPG: iPhone photos often show up as blank thumbnails on Windows or get rejected by upload forms. This tool decodes HEIC with libheif compiled to WebAssembly, right in the tab, and outputs JPG, PNG or WebP. Drop a batch and download a zip.

2. Image Resizer: resize before you compress. A 4000×3000 photo shown at 800×600 wastes bytes no matter how well you compress it. You can resize by percentage or exact pixels, or use social presets (X, LinkedIn, Instagram, YouTube and more).

3. Image Compressor: takes JPEG, PNG, WebP and AVIF in, and outputs MozJPEG, WebP, AVIF, or lossless PNG optimized with OxiPNG. One detail people miss: JPEG, WebP and AVIF are lossy at every quality setting, including 100%. If pixels must not change, choose PNG.

Before you publish a photo: open it in Media Info Viewer to see what EXIF data it carries (camera, timestamps, sometimes location).

When you need it in a script instead

Browser pages are right for one-off jobs, and anything that needs a local file, the camera or a canvas only works there. For repeatable transforms, FindUtils also has a REST API (387 tools) and an MCP server (388 tools) for AI clients. The catalog is described in an OpenAPI 3.1 spec and indexed in llms.txt. Every page also has a Markdown twin: add markdown.md to the path.

To set expectations: running a tool through the API or MCP needs an API key. Keys aren't for sale yet, and early access goes through the contact page. The catalog and schemas are open to read, and the browser tools need no key.

The short version

Test the "no upload" claim with the Network tab instead of trusting a badge.
JSON: format → diff → generate types. Don't expect CSV to keep your types.
PDF: merge → number → compress → strip metadata last.
Images: convert → resize → compress, and check EXIF before you publish.

Everything above is free at findutils.com. If a tool is missing from your workflow, there's a request page. I read those.

Olgun Özoktaş builds and reviews the tools on FindUtils.