DEV Community: Felix ZHU

A black box is not redaction — and three other things I got wrong building local PDF tools

Felix ZHU — Thu, 12 Nov 2026 12:28:33 +0000

Take any PDF. Draw a black rectangle over a line of text in a viewer that lets you annotate. Save it. Open it again and drag-select across the rectangle.

The text comes back.

That is the entire reason I built a PDF tool site, and it is also the first thing I got wrong.

A black box is a drawing, not a deletion

An annotation is an object layered on top of the page content. The characters underneath are still there, in the content stream, encoded exactly as they were before you covered them up. Select-all still finds them. Copy still copies them. Any text extractor still returns them.

Actual redaction means the characters stop existing in the file. Not hidden, not covered, not rendered white-on-white — gone from the content stream, so that extraction returns nothing.

I built the redaction tool around that distinction, and then I made the checker report a number instead of a picture. Counting characters inside the marked areas turns out to be the only way to tell a real deletion from a good-looking one.

Three different zeros

This is the part that took me longest to get right, and it is the part most redaction tools skip.

If the checker says "0 characters inside the marked areas," that sentence can mean three completely different things:

The text is gone. The page had a text layer, you marked it, and now extraction returns 0. This is the result you want, and the report calls it CLEARED.
There was never a text layer. The page is a scan. Every pixel is an image; there are no characters to find in the first place. The tool reports NOTHING TO MEASURE, because the 0 is the absence of a measurement, not a clean result. A scanner output can look identical to a properly redacted page and mean the opposite thing — one has no text because it never did, the other has no text because you removed it.
You drew the box on empty space. Same 0, same false comfort. The text you meant to remove is three lines down.

The first version of my checker merged all three into a single "0" with a green tick. That is a security product telling you what you want to hear. The current version reports the source page's character count next to the output's, so a scan and a clean redaction can never look the same.

There is a fourth result, and it is the ugly one: the marked page still hands back extractable text after processing. The report says so in plain words and tells you to treat the output like the original. It has happened in testing. I would rather the tool say that than round up to success.

What actually happens to the file

The redaction runs locally: the page is rendered to a canvas at 2× (about 144 DPI), the marked pages are rebuilt as JPEGs at quality 0.9, and the result is assembled into a new PDF. Pages you did not mark are copied through with their original text layer intact.

That has a consequence the tool states on the report rather than hides: a rebuilt page is an image, so everything on it stops being selectable — including the text that was not inside a box. If you need the rest of the page to stay searchable, you cannot have that and a destroyed text layer on the same page. Pick which one matters for this document.

The leak nobody looks at

Redaction is about what is visible. Metadata is about what is attached.

I stripped Title, Author, Subject and friends, and the file still carried the old title. The cause: pdf-lib removes the catalog's reference to the XMP packet, but the packet itself survives as an unreferenced indirect object inside the document. Delete the pointer and the body stays.

The second mistake was the check. I searched the output bytes for x:xmpmeta and found nothing, so I called it clean. The object was compressed. A byte search over a deflated stream tells you nothing at all — and this is exactly the kind of false pass that makes a verification step worse than no verification step.

The fix was to enumerate every indirect object after stripping, decompress each stream (UTF-8 first, then deflate, then raw deflate), and count the ones that still contain an XMP packet. Streams over 5 MB are reported as unscanned rather than silently skipped, because "I did not check this" and "this is clean" are different answers.

On my test file: 1,634 bytes in, 766 out, no XMP left. Compressed variant: 1,256 to 754.

Two more surprises, both about what tools quietly drop

Rebuilding a PDF is a destructive operation and the destructive part is not always where you expect.

PDFDocument.create() plus copyPages does not carry Author, Title or XMP into the new document — so a merge tool built this way produces a file with the contents of both inputs and the metadata of neither. It also stamps its own Producer and Creator as pdf-lib (...). If you were merging to preserve a document's provenance, you did not.

Same for splitting: each part is a fresh document, so each part arrives with no author and no title, whatever the original had. A tool page claiming otherwise is a page contradicting its own code.

The page-level limits are equally unglamorous: splitting one page per file caps at 50 pages, converting to JPG caps at 100, redaction caps at 50, and every tool caps the upload at 100 MB. These are browser limits, not policy — past that point memory pressure starts killing tabs, and a tool that crashes halfway is worse than one that refuses up front.

How to check that nothing is uploaded

This is the claim everything else rests on, so it should be falsifiable in ten seconds rather than taken on trust.

Open the tool, open the browser's Network tab, and drop a file in. You will see no request carrying your document. What you will see is static assets, and Cloudflare's analytics beacon, which the host injects into every page it serves — that is the CDN counting visits, not your file going anywhere. Clear the log, process the file, and watch it stay empty.

Five tools, all of them local

Everything above is implemented in the browser with pdf-lib and pdf.js. No server, no queue, no upload step, because there is nothing to upload to.

Redact a PDF without uploading it — draw boxes, rebuild the marked pages as images, get a report that separates the three zeros. Not a certification, not legal advice, and not a substitute for a compliance workflow that requires one.
Strip metadata from a PDF — Info dictionary and XMP, verified by decompressing every object rather than trusting the pointer deletion.
Merge PDFs in the browser — page contents carried, metadata deliberately not.
Split a PDF into single pages — one file per page or fixed ranges, zero-padded names so part10 sorts after part9 and not before part2.
Convert PDF pages to JPG — 144 or 216 DPI, quality 0.92 fixed, one download per page or a single ZIP.

Disclosure: these are my own tools. No affiliate links, nothing paid, no account required.

If you need redaction that survives opposing counsel, this is not that product, and I would rather say so here than in a support email. What it is: a local check you can run before you send a file you are not sure about.

PDF to JPG in the browser: three problems the tutorials skip

Felix ZHU — Sun, 08 Nov 2026 10:16:50 +0000

Last month I had to turn a 40-page PDF into images. The reason was embarrassingly small: a form that only accepted JPG. Print to PDF had gotten me a document I could read but not upload, and every converter I found wanted the file on their server first.

So I built the conversion into a tool that already runs entirely in the browser. The happy path is about twenty lines of code. The rest of this post is the three things that broke after those twenty lines worked, all of which I only found by actually running it on real documents.

The twenty lines

pdf.js renders a page onto a canvas, the canvas becomes a blob, the blob becomes a file.

const pdf = await pdfjsLib.getDocument({ data: bytes }).promise;

for (let i = 1; i <= pdf.numPages; i++) {
  const page = await pdf.getPage(i);
  const viewport = page.getViewport({ scale: 2 });

  const canvas = document.createElement('canvas');
  canvas.width = viewport.width;
  canvas.height = viewport.height;

  await page.render({
    canvasContext: canvas.getContext('2d'),
    viewport
  }).promise;

  const blob = await new Promise(res =>
    canvas.toBlob(res, 'image/jpeg', 0.92)
  );
}

That produces a file. It also produces a file that is wrong in three ways I did not notice until I opened one.

Problem one: your JPEG has a black background

This is the one that surprised me most, because it fails silently and looks like a rendering bug.

A PDF page has no background colour. The page is a set of drawing operations floating on nothing. When pdf.js renders onto a canvas, the areas no content covers keep the canvas's initial state, which is fully transparent — rgba(0, 0, 0, 0), not white.

PNG can store that. JPEG cannot. JPEG has no alpha channel, so when you call toBlob with image/jpeg, the browser composites the transparent pixels against black. A white page with two paragraphs of text becomes a black page with two paragraphs of text.

The fix is one line before rendering:

const ctx = canvas.getContext('2d');
ctx.fillStyle = '#ffffff';
ctx.fillRect(0, 0, canvas.width, canvas.height);
await page.render({ canvasContext: ctx, viewport }).promise;

Worth noting: this is not a pdf.js defect. It is the correct behaviour for a renderer that does not invent a background the document never declared. But every tutorial I read skipped it, and so did I, until I opened the output.

Problem two: `scale` is not a zoom level, it is DPI

The natural reading of getViewport({ scale: 3 }) is "three times bigger". What it actually means is three times the PDF user-space unit, and one user-space unit is 1/72 inch. So:

scale	A4 pixel size	effective DPI
1	595 × 842	72
2	1190 × 1684	144
3	1785 × 2526	216

That matters because the number people care about is DPI, not scale. 72 renders fine on screen and looks blurry the moment it is printed or shown on a high-density display. 144 is the everyday setting. 216 is close to print quality and produces files several times larger for the same page.

My tool exposes these as buttons labelled Small, 72 DPI / Standard, 144 DPI / High, 216 DPI rather than 1x / 2x / 3x, precisely because "3x" tells you nothing about what you are going to get.

Problem three: canvas fails silently when it gets too big

This is the one that will bite anyone converting large-format documents rather than A4.

Browsers cap how large a canvas can be. The limits differ by engine and by platform, and — this is the annoying part — an oversized canvas usually does not throw. It returns a blank or partially drawn surface, and your code continues happily, producing empty JPEGs. iOS Safari is considerably stricter than desktop Chrome, so a document that renders correctly on your laptop can come back as solid white rectangles on a phone.

Two defences are worth having:

Check the dimensions before you allocate, and refuse the page with a real message instead of producing a blank image. A page 7152 × 10110 (A0 at scale 3) is well past what several browsers will give you.

Cap the total work. Mine is 100 pages per run. Not because 100 is a magic number, but because the alternative is a tool that accepts a 400-page catalogue and then dies halfway through with no explanation.

The memory arithmetic nobody does

A single A4 page at scale 3 allocates 1785 × 2526 × 4 bytes — about 17 MB of canvas backing store. Hold all 100 pages and you are at 1.7 GB before a single JPEG exists.

So pages have to be processed one at a time, and the canvas has to be released before the next one:

canvas.width = 0;
canvas.height = 0;

Then there is the archive. Collecting 100 JPEG blobs and handing them to a ZIP library means the whole output exists twice in memory at once. At an average 2 MB per page that is another 200 MB. On a desktop it survives. On a phone it is the difference between a finished download and a browser that closes the tab.

The honest answer is that batch size is not a product decision, it is a memory decision. If the limit feels arbitrary, it is — it is set by the smallest device I was willing to support.

What the output cannot do, and why I did not fix it

The output is a bitmap. There is no text layer inside it. Nobody can select the words, search them, copy them, or extract them, and a screen reader has nothing to read. If the PDF needs to stay searchable later, converting it to images is the wrong operation and no amount of engineering changes that — the text is being discarded on purpose, because discarding it is the point.

I also do not let you convert only pages 12 through 20. The tool converts the whole document. A range selector is easy to add and I have not added it, because the UI currently has one file input, one format toggle, one resolution toggle and one button, and every control I add has to be explained to someone who has never thought about DPI. That tradeoff is a choice, not an oversight, and it may change.

When not to use this

If the file is going to be printed, 216 DPI and a look at the first page before you commit to the batch.

If the file has to remain searchable, keep the PDF.

If it is a scan, converting it changes nothing — it already has no text layer, and you are paying DPI cost for an image you could have had.

If it is 300 pages, split it first, then convert the parts.

The tool

I built this as one of six small PDF utilities that all run locally — no upload, no account, no server to trust with the file. The rendering happens in the tab and the file never leaves it.

If you want to convert a PDF to JPG without uploading it, that is the page. The JPG/PNG toggle, the three DPI settings, and the ZIP download are all there, along with the text above about what the conversion costs you.

I am the person who wrote it, so treat the recommendation accordingly. The measurement that matters is your own: open the first output file before you run the batch.

The black box doesn't delete the text

Felix ZHU — Sun, 08 Nov 2026 08:52:32 +0000

Draw a black rectangle over a name in a PDF, export the file, then reopen it with pdf.js and call getTextContent(). The name comes back. Word for word, character for character.

That was the first thing I ran into when I started building a redaction tool that runs entirely in the browser. A black rectangle is a drawing instruction. It sits on a layer above the page. The text object underneath does not know or care that something was painted over it.

Most tools in this space deal with that in one of two ways. Some rewrite the content stream and genuinely remove the text. Some render the page to an image and throw the text layer away. Both approaches work. The problem is what happens after: the tool says "done", and you have no way to know which of the two just happened, or whether it actually worked on the region you marked.

Three different zeros

If you build a checker that counts how many characters can still be copied out of the area a user marked, you end up with three situations that all report zero:

The box missed. You drew over whitespace. There is no text there, so zero characters is the correct answer to a question nobody meant to ask.
The page is a scan. There is no text layer at all. Zero characters is correct, but it tells you nothing about whether the black box covers what you think it covers.
It worked. The text is gone.

Two of those zeros mean "there was nothing to delete". One means "deleted". A tool that only ever reports zero cannot tell you which one you are looking at, and the difference matters a lot: in case 2 you are trusting a rectangle you drew by eye, over an image you cannot read the text of.

So the check has to say which zero it is, out loud.

How to count characters inside a rectangle

pdf.js gives you the text items for a page, but the coordinates are in PDF space, not canvas space. Text position lives in item.transform, a six-value matrix, and the useful parts are the translation values. Util.transform converts them into the viewport coordinate system you drew the box in.

import { Util } from 'pdfjs-dist';

const page = await doc.getPage(pageNumber);
const viewport = page.getViewport({ scale: 1 });
const content = await page.getTextContent();

let charsInBox = 0;

for (const item of content.items) {
  if (!item.str) continue;

  const tx = Util.transform(viewport.transform, item.transform);
  const x = tx[4];
  const y = tx[5];
  const w = item.width * Math.abs(tx[0]);
  const h = item.height * Math.abs(tx[3]);

  // box is { x, y, w, h } in the same top-down viewport space
  if (x < box.x + box.w && x + w > box.x &&
      y < box.y + box.h && y + h > box.y) {
    charsInBox += item.str.length;
  }
}

That is the whole idea. Everything else is bookkeeping you have to add around it: which page, which box, how many boxes hit something, and whether the page has any text at all.

I made the check a button instead of an automatic step

Upload, redact, check, report. That flow would have been smoother, and I did not build it.

The check is a button the user presses on purpose. My reasoning: if the tool checks silently, people read the result as "the tool says it is fine" and move on. If someone presses a button and gets back 50 characters can still be copied out of 1 marked area., they have to decide what to do about that number. It belongs to them, not to a step they did not notice running.

The same logic applies to the export. After flattening, the tool reopens its own output and counts again. It does not say "done" and stop there. It says 210 extractable characters remain, on 2 pages. or 0 extractable characters across 3 pages. Those are different sentences because they are different outcomes.

The cost of making text stop being copyable

In a browser there is only one reliable way to make text stop being extractable: make the page stop being text.

If the text object exists in the content stream, pdf.js will find it. So will any other PDF reader, and so will anyone who opens the file with a text editor and looks at the objects. Painting over it does not remove it.

So the redaction path is: render the marked page at 2x scale, fill the boxes with black, encode the result as JPEG at quality 0.9, then embed that image as a full-page content stream on a fresh page. Pages you did not mark are copied through unchanged.

The cost of that is real, and it is not small:

That page is no longer searchable.
Nobody can select or extract text from it.
File size goes up, because a JPEG covering a whole page is usually larger than the text it replaced.
If the page had selectable text that other people needed, that text is gone now.

I put that on the page instead of in a footnote. A redaction tool that hides the tradeoff is asking to be trusted about the wrong thing.

Numbers from my own test files

Concrete results, not marketing claims.

A 3-page test file, one page marked: the export turned that one page into an image and copied the other two through unchanged. Re-checking the output found 210 extractable characters remain, on 2 pages. That is the honest outcome. I redacted page 1, pages 2 and 3 still have their text, and the checker says so rather than reporting zero.
The same file with all 3 pages marked: 0 extractable characters across 3 pages.
A 2-page scan with no text layer at all: pressing the check before exporting told me the page had no text layer. It did not report zero characters and leave me guessing.
A box drawn over empty whitespace: the check said the box missed.
A box over a line containing a fake name and a fake SSN: 50 characters can still be copied out of 1 marked area.

That last number is the one I keep coming back to. Fifty characters is a short line. If a tool had painted a black bar over it and told me the redaction was complete, I would have believed it.

What the other tools do

I looked at the direct competitors before writing any of this. Several are in a similar position: client-side, free, no upload, redaction that happens in the tab.

The one closest to identical in stack and pitch — same library pair, same "no upload" claim, showing up in search results for these queries — had a toolbar with Open PDF, Undo, Clear All, Prev, Next, Download, and one status message on save: Saved as ... — text layer permanently destroyed.

No character count. No re-check of the output. No mention of what happens on a scanned page.

I do not read that as dishonesty. I read it as an unexamined assumption: a box was drawn, so the text must be gone. The assumption holds in most cases and quietly fails in exactly the three cases at the top of this post.

What the check will not tell you

It counts characters that can still be copied out of the regions you marked. It does not tell you that a redaction satisfies any legal, medical, or regulatory standard, and it cannot. What number is low enough for your situation depends on your situation, your counterparty, and possibly your lawyer. A browser tab is not the place to answer that.

If the number is zero and the page has no text layer, the tool will say the page has no text layer. That is the point: you should be able to tell "nothing left to copy" apart from "nothing there to begin with".

The tool is at privacypdf.org/redact-pdf. It runs in the tab, nothing is uploaded, and there is no account. If you try it, start with the check button: draw a box over something you know is in the file, press Check, and look at the number before you export anything.

Semrush After the Adobe Acquisition: A 30-Day Paid Review (with two corrections)

Felix ZHU — Tue, 27 Oct 2026 14:56:45 +0000

Semrush After the Adobe Acquisition: A 30-Day Paid Review

TL;DR — Semrush is the most complete all-in-one SEO platform I've used since Adobe closed the $1.9B acquisition in April 2026. The expanded keyword index surfaces genuinely useful long-tail terms, and the new AI Visibility module is the first LLM coverage signal I've gotten from an SEO tool. But the content tools are locked behind the Guru plan, entry is single-seat, and the out-of-the-box audit is so noisy it says more about the crawl settings than about your site.

This is a paid 30-day test, not a sponsored piece. No vendor contact, no review copy, no free access.

How I tested

I ran a paid Semrush subscription for 30 days and used it across three real client projects: a small SEO/content site (14 pages), an e-commerce store (~220 pages), and a B2B SaaS marketing blog (~60 pages).

I deliberately did not run the whole toolkit at once. I picked the modules I'd actually use as a solo operator — keyword research, content optimization, site audit, and the new AI Visibility feature — and forced myself to log what each one returned before configuring anything.

Surprise #1: the keyword index actually surfaced long-tail terms

I assumed the headline index size was vanity marketing. It's not entirely.

Across the three projects, Semrush surfaced low-volume long-tail terms that my previous tool hadn't shown me — mostly terms with clear search intent that I could target with a dedicated page. On the content site alone, I found 12 non-obvious, low-competition keywords that matched the site's topical coverage but weren't in the other tool's suggestions.

The correction I owe you: the raw index count is still a vanity number. What matters is how many of those terms have real volume. When I checked a sample of the "new" terms the index surfaced, some had volume and plenty were crawler artifacts. Don't quote the index size as proof of anything — but the coverage itself has genuinely improved.

Surprise #2: AI Visibility is the first LLM coverage signal I've seen

The AI Visibility module tracks brand mentions inside ChatGPT, Claude, and Perplexity. For a site that gets meaningful AI-referral traffic, this is the most interesting thing Semrush has shipped this year. It won't tell you why a model cites you, and it's not deep citation tracking yet — but just knowing whether your brand shows up in a model's answer, and roughly how often, is something no other tool I've used gives me out of the box.

The module is still early. The signal is directional, not precise, and it treats some verb-based brand names poorly (it confused a client's name with a common verb). I'd use it as a monitoring layer, not a source of truth.

Two corrections I owe this community

I posted an earlier version of this on Reddit and got corrected on two points. Both were right.

The "280B keyword index" framing was overblown. As I said above, the raw count is vanity until you filter by real volume. I've stopped leading with the number and now lead with coverage on actual terms.
"3,800 audit issues on 220 pages" was a bad complaint. That number is what a default crawl spits out on a site that size — roughly 17 issues per page, which is unremarkable. Once I adjusted the audit thresholds (excluding cosmetic warnings, focusing on critical + high), the report became useful instead of scary. The noise was my configuration problem, not the tool's.

Where Semrush still falls short

Content tools are paywalled behind Guru. On Pro, the content workflow is thin. You can find keywords, but the full writing/optimization stack — the AI Content Writer and advanced content analytics — sits behind the mid-tier plan. For a solo operator this is the difference between $130/mo and $250/mo for the part of the tool most people actually use daily.
Single-seat entry plans. There's no cheap solo seat. If you're a one-person site, the entry price buys a lot of modules you may never open.
The audit is noisy out of the box. It takes a session to configure thresholds before the site audit tells you something real. That's a learning curve, not a bug — but it's worth budgeting an hour for on setup.
Pricing creep. Annual billing is the only sane option for a solo operator; the gap between Pro and Guru is the real decision point, and it's wide.

Pricing (verified October 2026, from Semrush's official pricing)

Plan	Price (annual, per month)	Who it's for
Pro	~$130	Solo operators, basic keyword + position tracking
Guru	~$250	Teams that need the content toolkit, PPC, and social
Business / Enterprise	Custom	Agencies and larger orgs

The honest math for a solo operator: Pro gets you the data layer, but the content layer — the part that justifies the subscription for most content marketers — lives at Guru.

Who this is for / who it isn't

Good fit: content teams and SEOs who want one source of truth for keyword research, rank tracking, and content monitoring, and who are willing to configure the audit once.

Not a good fit: pure content-only users who just want on-page optimization (Surfer is cheaper and better for that), or anyone producing under 5 articles a month — the ROI doesn't justify the entry price at low volume.

Semrush vs. Ahrefs, briefly

The honest comparison: Ahrefs is stronger for backlink analysis and, in my experience, slightly cleaner for pure keyword discovery. Semrush's edge is breadth — you get PPC, social, content, and AI visibility in one place. If you're a one-tool operator covering multiple channels, Semrush wins. If you live and die by link building, Ahrefs is still the specialist.

For a deeper side-by-side I tested over 30 days, see Semrush vs Surfer SEO and the full Semrush review.

Bottom line

Semrush post-acquisition is the most complete all-in-one I've used. "Complete" and "bloat" are the same product — it depends on whether you turn things on deliberately. Configure the audit, filter keywords by real volume, and treat AI Visibility as a directional signal, and it's genuinely useful. Skip that discipline and it's a $250/mo noise generator.

Disclosure: I run a niche SEO tools site and this post links to pages on it, some of which contain affiliate links. This review reflects a paid 30-day test with no vendor sponsorship; opinions are mine and based on what I actually used.

description: 30 days on a paid Semrush plan after the Adobe deal — two real surprises, two corrections I owe the SEO community, honest pricing, and where it still falls short.
tags: seo, semrush, ahrefs, marketing
canonical_url: https://nicheaitool.com/semrush-review

I Tested Semrush for 30 Days After the $1.9B Adobe Acquisition — Here's What Actually Changed

Felix ZHU — Sun, 25 Oct 2026 02:08:04 +0000

Adobe closed a $1.9B acquisition of Semrush in April 2026. As a solo developer who does SEO, PPC and content for client sites, I wanted to know if the "new Semrush" was worth the premium pricing — so I ran a 30-day test across real projects: site audits, keyword gap analysis, PPC research, social tracking and content scoring.

What actually changed post-acquisition:

Keyword database jumped to 280B (from ~24B), and it's now the largest in the category.
AI Visibility — tracks your brand mentions across ChatGPT, Claude and Perplexity (31M+ prompts monitored). I confirmed this surfaces real mentions I couldn't find with a manual search.
MCP connectors — native Semrush data inside Claude/ChatGPT/Perplexity. This is genuinely new; no competitor ships this out of the box yet.
Content tools and historical data are still locked behind the Guru plan ($249.95/mo), which is a real cost wall.

The honest cons: entry plans are single-seat (even Business starts with 1 user), a 220-post site triggered 3,800+ audit issues, and the AI writing output still needs heavy editing. And there's no self-serve cancellation.

If you're weighing Semrush vs Ahrefs for an all-in-one stack, I wrote up the full 30-day breakdown with per-module scores at [https://nicheaitool.com/semrush-review] — including who should skip it.

30+ free SaaS calculators for founders — revenue, CAC, churn, LTV:CAC, ROAS, conversion rate, and more. All run in your browser. No sign-up, no data collection, no tracking. Built because I was tired of blog posts that say "3:1 LTV:CAC is good"

Felix ZHU — Sun, 11 Oct 2026 05:31:38 +0000

Felix ZHU

Oct 11

30+ Free SaaS Calculators and Tools for Founders (2026)

#sass #calculator #productivity #marketing

4 min read

30+ Free SaaS Calculators and Tools for Founders (2026)

Felix ZHU — Sun, 11 Oct 2026 05:29:35 +0000

Every founder I know has the same problem: you know you should track your metrics, but pulling the numbers together takes forever.

You open a spreadsheet. You Google "what's a good LTV:CAC ratio." You find three blog posts with three different answers. You close the spreadsheet. Sound familiar?

I built Niche AI Tool because I was tired of this cycle. Instead of writing another opinion blog post, I built free calculators that actually solve the problem. All of them run 100% in your browser — no sign-up, no data collection, no tracking.

Here's the full collection.

Revenue & Metrics Calculators

The core stuff. If you only use three tools from this list, make it these three.

SaaS Revenue Calculator — MRR, ARR, runway, growth rate. The starting point for any SaaS metrics check.

MRR Growth Calculator — Month-over-month growth with CAGR. See if your growth is accelerating or decelerating.

CAC Calculator — Customer acquisition cost with payback period. Find out how long it takes to earn back what you spent to get a customer.

Churn Rate Calculator — Monthly churn with revenue impact. A 5% churn rate doesn't sound bad until you see it means 46% annual churn.

LTV:CAC Ratio Calculator — The magic ratio every SaaS founder needs. 3:1 is the floor, not the goal.

Profit Margin Calculator — Gross vs net margin breakdown. See where your money is actually going.

Conversion Rate Calculator — Website conversion rate, CPA, and revenue per visitor. Includes industry benchmarks (e-commerce 2-3%, SaaS 5-10%, B2B 2-5%).

Marketing & Ads Calculators

ROAS Calculator — Return on ad spend with break-even analysis. Find out if your ads are actually profitable.

ROI Calculator — General-purpose ROI with timeline. Good for any investment decision.

CPM Calculator — Ad cost per thousand impressions. Compare ad platforms apples-to-apples.

Email Open Rate Calculator — Benchmark against industry averages. If your open rate is below 15%, something's wrong with your subject lines or list quality.

UTM Link Builder — Campaign URL builder with presets. Stop guessing which channel is driving traffic.

AI & Developer Tools

AI Tool ROI Calculator — Are your ChatGPT, Claude, and Cursor subscriptions actually worth it? Input your hourly rate, weekly usage, and subscription stack to see your real ROI. I've had people tell me they cancelled $80/month of unused subscriptions after using this.

Stripe MCP Config Validator — Paste your MCP JSON, detect secret-key leaks before you deploy. Runs entirely in your browser, so your keys never leave your device.

Cold Email ROI Calculator — See if your cold email campaigns are actually profitable.

Cold Email Reply Rate Calculator — Benchmark your reply rates against industry data.

Reviews & Comparisons

Calculators are great for your own metrics, but what about the tools you're paying for?

I also publish data-backed reviews — every one aggregates thousands of real user ratings from G2, Capterra, and Trustpilot. No paid placements, no sponsored rankings.

Head-to-head comparisons:

Lemlist vs Instantly — Which cold email tool wins in 2026?
Jasper vs Copy.ai — AI writing tools compared
Ahrefs vs Semrush — SEO tools showdown

Deep reviews:

Jasper Review — 4.7/5 G2, but 3.5/5 Trustpilot. The rating gap tells the real story.
Instantly.ai Review
Smartlead Review

Why All Free?

Good question. Here's the honest answer:

Tool pages rank better than blog posts. People search for calculators, not opinions. Google knows this and rewards pages that satisfy the query completely.
Engagement is 10x higher. People spend 2-3 minutes using a calculator. They spend 30 seconds skimming a blog post.
No backend = no cost. All calculators are pure HTML + JavaScript, deployed on Cloudflare Pages for free. No servers, no databases, no maintenance.
Your data stays yours. Every calculator runs locally in your browser. Your revenue numbers, ad spend, and customer counts never touch a server.

Start Here

If you're new, start with the SaaS Revenue Calculator. It takes 30 seconds and will tell you more about your business than most dashboard tools.

Then check your LTV:CAC ratio. If it's below 3:1, you have a problem that no amount of growth will fix.

All tools are free, forever. No credit card, no email gate, no bullshit.

Explore all 30+ free tools →

Disclosure: This contains affiliate links. If you sign up through these links, we may earn a commission at no extra cost to you.

I Built 14 Free Calculators to Get SEO Traffic — Here's What Worked

Felix ZHU — Thu, 01 Oct 2026 09:24:08 +0000

The Problem: Blogging Takes Too Long

Like every indie hacker, I started with a blog. I wrote 30+ articles about AI tools, spent hours on keyword research, and waited for Google to notice me.

Six months later? 12 visitors a day. Most of them from my mom clicking to be supportive.

The problem was obvious: every AI tool review blog says the same thing. "ChatGPT is great for writing. Claude is great for coding. Cursor is great for..." You've read it a hundred times. I was adding noise to a noisy room.

The Pivot: Tools Instead of Articles

I had a simple realization: people search for calculators, not opinions.

When someone types "SaaS revenue calculator" into Google, they don't want a 2,000-word blog post. They want to type in their numbers and get an answer. And Google knows this — tool pages rank higher because they satisfy the query completely.

So I stopped writing reviews and started building tiny calculators. Each one took 2-4 hours. Pure HTML + JavaScript, no backend. Deployed on Cloudflare Pages for free.

What I Built (14 Tools and Counting)

Here's the current lineup:

Revenue & Metrics (the core)

SaaS Revenue Calculator — MRR, ARR, runway, growth rate
MRR Growth Calculator — month-over-month growth with CAGR
CAC Calculator — customer acquisition cost with payback period
Churn Rate Calculator — monthly churn with revenue impact
LTV:CAC Calculator — the magic ratio every SaaS founder needs

Marketing & Ads

ROAS Calculator — return on ad spend with break-even analysis
ROI Calculator — general-purpose ROI with timeline
Conversion Rate Calculator — A/B test significance checker
Email Open Rate Calculator — benchmark against industry averages
Profit Margin Calculator — gross vs net margin breakdown
CPM Calculator — ad cost per thousand impressions

AI & Developer Tools (the new direction)

AI Tool ROI Calculator — are your ChatGPT/Claude/Cursor subscriptions actually worth it?
Stripe MCP Config Validator — paste your MCP JSON, detect secret-key leaks before you deploy
UTM Builder — campaign URL builder with presets

That last one — the AI Tool ROI Calculator — is currently my favorite. Every developer I know is subscribed to 3-5 AI tools and has no idea if they're getting value. The calculator lets you check your hourly rate, weekly AI usage, and subscription stack to see your real ROI. I've had people tell me they cancelled $80/month of unused subscriptions after using it.

The Results So Far

I won't pretend this is a viral success story. It's a slow burn, but the numbers are moving in the right direction:

Traffic: From 12 visitors/day to ~150 visitors/day in 3 months
Top pages: The calculators rank on page 1-2 for their target keywords
Bounce rate: 35% (people actually use the tools, then stay to browse)
Average session: 2:40 (they calculate, then click "More Free Tools")

The key insight: tool pages have 10x the engagement of blog posts. People spend 2-3 minutes actually using a calculator. They spend 30 seconds skimming a blog post. Google sees this engagement and rewards it.

What I Learned (The Hard Parts)

1. Interlinking matters more than I thought. Every calculator page links to 5-6 related calculators. This creates a "wiki effect" where Google crawls deep into the site. I added a "More Free Tools" grid to every page, and internal traffic doubled within a week.

2. Schema is non-negotiable. Every tool page has WebApplication + FAQPage JSON-LD. The FAQ schema alone got me rich snippets within 2 weeks. For the MCP validator, I also added HowTo schema (Paste → Validate → Review), which targets "how to" search queries.

3. Local processing is a selling point. Both the AI ROI Calculator and MCP Config Validator run 100% in the browser. I put "🔒 100% Local · No Sign-up" in the hero. People actually care about this — especially for the MCP validator where they're pasting API keys.

4. Don't build tools nobody searches for. I almost built a "invoice number generator" because it was technically easy. Then I checked search volume — basically zero. Every tool I build now starts with a keyword check. If nobody's searching for it, I don't build it.

5. The "per-tool ROI" feature almost got me in trouble. In the AI ROI Calculator, I initially showed "Keep / OK / Review" labels for each subscription. Then I realized: allocating total savings proportionally to cost is mathematically convenient but logically flawed. A $20 tool doesn't necessarily save more time than a $10 tool. I changed the labels to "High / Moderate / Low" and added a big warning: "This is only a rough mathematical approximation. Real-world individual tool ROI cannot be isolated without separate A/B testing." Honesty > false precision.

The Monetization Question

Right now, these are free tools with no direct revenue. The plan is:

Traffic first. Get to 500+ visitors/day before worrying about monetization.
Affiliate links. The calculators naturally mention tools (Stripe, Shopify, AI tools) — I'll add affiliate links where relevant.
Premium templates. I already sell a Stripe MCP Prompt Pack ($19 one-time). The free validator drives traffic to it. More paid templates are coming.
Newsletter. A simple "get new free tools monthly" signup. Not launched yet, but the audience is building.

What's Next

I'm adding 1-2 calculators per month. The next ones in the pipeline:

Break-even calculator for new products
Email subject line tester (scoring, not generation)
Pricing page analyzer (paste your pricing, get conversion heuristics)

If you're an indie hacker struggling with blog traffic, I'd strongly consider the tool-pivot. It's more work upfront (you have to actually build something), but the traffic quality is dramatically higher. People don't just read your tool — they use it, bookmark it, and share it.

Built a Free SaaS Metrics Calculator — Here's the Math Behind It

Felix ZHU — Thu, 10 Sep 2026 11:54:59 +0000

As a developer, I hate spreadsheets.

Every time I needed to calculate runway, LTV, or CAC payback for a project, I'd open Google Sheets, build a formula, and inevitably mess up the cell references. After the third time I accidentally calculated runway using the wrong burn rate, I decided to build a tool.

The result: a free SaaS Revenue Calculator that runs entirely in the browser.

The Math Behind the Metrics
Here's what the calculator computes and how.

Runway
javascript
// Runway = Cash in bank / Net monthly burn
const runway = cashInBank / netBurn;

// Net burn = Monthly costs - MRR
const netBurn = monthlyCosts - mrr;

// If netBurn is negative, you're profitable and runway is infinite
if (netBurn <= 0) return Infinity;
Runway tells you how many months until you run out of cash. If your MRR exceeds operating costs, you're profitable and runway is effectively infinite.

LTV (Lifetime Value)
javascript
// LTV = ARPU / Monthly churn rate
const arpu = mrr / activeCustomers;
const ltv = arpu / monthlyChurnRate;
LTV is how much revenue an average customer generates before they churn. Higher is better. A healthy LTV:CAC ratio is 3:1 or higher.

CAC Payback
javascript
// CAC Payback = CAC / (ARPU * Gross Margin)
const cacPayback = cac / (arpu * grossMargin);
CAC payback is how many months it takes to recover acquisition costs. Under 12 months is good. Under 6 months is excellent.

Why I Built This
I was tired of:

Manual calculations — Building the same formulas in every new spreadsheet

Opaque tools — Existing calculators that don't show their math

Paywalls — Tools that charge $50/month for basic arithmetic

The calculator is free, runs locally, and shows you exactly how each metric is computed.

Technical Implementation
The calculator is a single HTML file with vanilla JavaScript. No frameworks, no build step, no dependencies. It runs entirely client-side — your financial data never leaves your browser.

Key design decisions:

Real-time updates: Every input change recalculates all metrics instantly

12-month projection: Uses compound growth to project MRR forward

Health indicators: Each metric shows a green/yellow/red status based on benchmarks

When to Use This
Before a fundraise — Investors will ask about LTV:CAC, CAC payback, and net burn. Get your numbers straight.

When deciding to hire — See how adding a salary affects your runway.

When evaluating churn — Model how reducing churn from 5% to 3% changes LTV and runway.

→ Try the calculator

FAQ
Can I self-host this?

The calculator is a static HTML file. You can save it locally and run it offline.

Does it store my data?

No. Everything runs in your browser. No server calls, no analytics, no storage.

What's Next
I'm planning to add:

Scenario comparison (side-by-side what-if analysis)

Export to CSV/PDF

Cohort retention modeling

If you have feature requests, let me know.

Disclosure: This article contains affiliate links. If you sign up through these links, we may earn a commission at no extra cost to you.

DEV Community: Felix ZHU

A black box is not redaction — and three other things I got wrong building local PDF tools

A black box is a drawing, not a deletion

Three different zeros

What actually happens to the file

The leak nobody looks at

Two more surprises, both about what tools quietly drop

How to check that nothing is uploaded

Five tools, all of them local

PDF to JPG in the browser: three problems the tutorials skip

The twenty lines

Problem one: your JPEG has a black background

Problem two: scale is not a zoom level, it is DPI

Problem three: canvas fails silently when it gets too big

The memory arithmetic nobody does

What the output cannot do, and why I did not fix it

When not to use this

The tool

The black box doesn't delete the text

Three different zeros

How to count characters inside a rectangle

I made the check a button instead of an automatic step

The cost of making text stop being copyable

Numbers from my own test files

What the other tools do

What the check will not tell you

Semrush After the Adobe Acquisition: A 30-Day Paid Review (with two corrections)

Semrush After the Adobe Acquisition: A 30-Day Paid Review

How I tested

Surprise #1: the keyword index actually surfaced long-tail terms

Surprise #2: AI Visibility is the first LLM coverage signal I've seen

Two corrections I owe this community

Where Semrush still falls short

Pricing (verified October 2026, from Semrush's official pricing)

Who this is for / who it isn't

Semrush vs. Ahrefs, briefly

Bottom line

I Tested Semrush for 30 Days After the $1.9B Adobe Acquisition — Here's What Actually Changed

30+ free SaaS calculators for founders — revenue, CAC, churn, LTV:CAC, ROAS, conversion rate, and more. All run in your browser. No sign-up, no data collection, no tracking. Built because I was tired of blog posts that say "3:1 LTV:CAC is good"

30+ Free SaaS Calculators and Tools for Founders (2026)

30+ Free SaaS Calculators and Tools for Founders (2026)

Revenue & Metrics Calculators

Marketing & Ads Calculators

AI & Developer Tools

Reviews & Comparisons

Why All Free?

Start Here

I Built 14 Free Calculators to Get SEO Traffic — Here's What Worked

The Problem: Blogging Takes Too Long

The Pivot: Tools Instead of Articles

What I Built (14 Tools and Counting)

The Results So Far

What I Learned (The Hard Parts)

The Monetization Question

What's Next

Built a Free SaaS Metrics Calculator — Here's the Math Behind It

Problem two: `scale` is not a zoom level, it is DPI