Mukesh Maddheshiya

Posted on Mar 14

How I Built 200+ Free Browser-Based Tools with Next.js 16 — No Backend Needed

#showdev #webdev #javascript #nextjs

Every time I needed to merge a PDF or compress an image, I'd land on some website that wanted me to sign up, upload my files to their server, and then pay for "premium."

I thought — most of these operations can run entirely in the browser. Why does my PDF need to touch someone else's server?

So I built ToolsArena — a collection of 200+ free tools that process everything client-side. No uploads, no signups, no backend.

What's Inside

The site covers 6 categories with 200+ tools:

PDF Tools — Merge, split, compress, Word to PDF, PDF to Excel, JPG to PDF. All using pdf-lib running in the browser.

Image Tools — Background remover, compressor, resizer, format converter, flip/rotate, photo effects. Canvas API does the heavy lifting.

Text Tools — Word counter, case converter, Lorem Ipsum generator, text-to-speech, reading time calculator.

Developer Tools — JSON formatter, CSS gradient generator, Base64 encoder/decoder, regex tester, color picker, URL encoder.

Calculators — EMI, compound interest, GST (India), EPF, percentage, age, BMI.

SEO Tools — Meta tag generator, Open Graph preview, reading time estimator.

Tech Stack

Next.js 16 (App Router)
TypeScript
Tailwind CSS
**pdf-lib for PDF operations
Canvas API for image processing
i18n via [locale] route segment (English, Hindi, Nepali)

Architecture: How 200+ Tools Share One Pattern

The key insight: almost every tool follows the same flow:

Instead of building 200 unique pages, I created a registry pattern:

// tools-registry.ts
{
  slug: 'pdf-merge',
  name: 'PDF Merge',
  description: 'Merge multiple PDFs into one',
  category: 'pdf',
  component: 'PdfMergeTool',
  relatedTools: ['pdf-split', 'pdf-compress'],
  // SEO metadata...
}

Each tool gets its own directory under src/app/[locale]/tools/[tool-slug]/ with:

page.tsx — static metadata + dynamic import
ToolComponent.tsx — the actual tool UI and logic

This pattern means adding a new tool takes about 1-2 hours:

Add registry entry (metadata, SEO, related tools)
Create the tool component
Done — routing, SEO, sitemap, related tools all handled automatically

Client-Side PDF Processing — It Actually Works

The biggest surprise was how capable pdf-lib is for browser-side PDF operations:

// Merge PDFs — entirely in the browser
import { PDFDocument } from 'pdf-lib';


async function mergePDFs(files: File[]) {
  const merged = await PDFDocument.create();

  for (const file of files) {
    const bytes = await file.arrayBuffer();
    const pdf = await PDFDocument.load(bytes);
    const pages = await merged.copyPages(pdf, pdf.getPageIndices());
    pages.forEach(page => merged.addPage(page));
  }

  return await merged.save(); // Uint8Array — download directly
}

No server. No API. No upload. The PDF never leaves the user's device.

This works for merge, split, compress, add watermark, rotate pages, and extract text.

Multilingual SEO — The Hidden Goldmine

The site supports 3 languages: English, Hindi (हिन्दी), and Nepali (नेपाली).

Here's what I discovered: Nepali keywords have near-zero competition.

For English, "pdf merge online free" has thousands of competing pages. But "PDF मर्ज गर्ने" (PDF merge in Nepali) has almost nobody competing. Same for Hindi — significantly less competition than English equivalents.

The implementation uses Next.js [locale] segments:

/en/tools/pdf-merge → English
/hi/tools/pdf-merge → Hindi

/ne/tools/pdf-merge → Nepali

With hreflang tags connecting all three versions. Each language has its own guides registry with culturally relevant content — not just Google Translate output.

Result: 878 statically generated pages across 3 languages, all pre-rendered at build time.

Content + Tools = SEO Compound Effect

Tools alone don't rank well on Google — users come, use the tool, and leave. Low dwell time, high bounce rate.

So I added detailed guides for each tool category:

"How to Merge PDFs — Complete Guide"
"Image Compression: When to Use JPEG vs PNG vs WebP"
"Understanding GST Calculation in India"

37 guides × 3 languages = 111 content-rich pages that keep users on the site longer and give Google more text to index.

Each guide links to the relevant tool, and each tool links back to its guide. This internal linking structure helps both rank better.

Static Generation at Scale

With 878 pages, build times started getting long. Some things that helped:

Dynamic imports for heavy libraries (pdf-lib is 300KB+ — only load it on PDF tool pages)
Incremental Static Regeneration for pages that don't change often
Shared layouts — the tool wrapper, navigation, and footer are shared across all 200+ tool pages

Current build: 878 static pages generated successfully including all locale variants.

What I'd Do Differently

Start with 20 tools, not 200 — I spent months building tools before focusing on SEO. Should have launched earlier with fewer tools and built traffic alongside development.
Write guides first, build tools second — The guides bring in search traffic. The tools convert that traffic into returning users. I did it backwards.
Focus on one language first — Maintaining content in 3 languages is a multiplier on every change. Starting with English-only and adding languages after establishing traffic would have been more efficient.

Numbers (Honest)

200+ tools live
37 guides × 3 languages = 111 content pages
878 total static pages
Traffic: still early, just starting to appear in Google results
Revenue: $0 (not monetized yet)
Total dev time: several months of side-project work

Try It

🔗 toolsarena.in

Everything is free. No signup. No file uploads. Your data stays in your browser.

I'd love feedback — what tools are missing? What would make you use this over iLovePDF or Smallpdf?

If you're building something similar, happy to share more details about the architecture, SEO strategy, or specific tool implementations in the comments.

DEV Community