How I built a file converter platform with a $0 backend (100% Client-Side Architecture)

Drlove Phukon — Fri, 10 Apr 2026 06:39:47 +0000

Every time I needed to quickly format a CSV dataset into JSON Lines or convert a Markdown file, I ran into the same annoying problem. The top Google results are always massive SaaS tools that demand an email signup, restrict file sizes, and worst of all—force you to upload your sensitive data to their backend servers.

I didn't want to upload my local database dumps to a random server just to change the format.

So, I built MyConverterPro: a suite of developer and document tools that forces the browser to do 100% of the heavy lifting. Zero backend infrastructure. Zero server costs. Total data privacy.

Here is the exact architecture, the packages I used, and the hard lessons I learned making the browser do the backend's job.

**The Stack & The State

To make this fast, the core is built on React 19 and Vite. Styling is handled by Tailwind 4 and Shadcn UI to keep the interface clean and out of the user's way.

Because there is no database, I had to figure out how to track usage limits (a soft paywall after a certain number of conversions) without requiring a login.
I used Zustand with local storage persistence. The store (useAppStore) splits state into two chunks:

Persisted: conversionCount and isPremium are saved directly to localStorage.

Session-only: adsWatchedThisSession resets on refresh, explicitly excluded using Zustand's partialize function.

**The Engine: Forcing the Browser to Work

**
The golden rule of the app: fetch() is never used to send a file payload. Everything happens in memory using the FileReader and Blob APIs.

Here is what is handling the heavy lifting under the hood:

PapaParse (CSV Processing): This is the workhorse for tools like CSV to JSONL and CSV to PDF. By parsing the file directly in the browser, I can map the data arrays instantly. For JSONL, the app iterates through the parsed rows, uses JSON.stringify, joins them with \n, and creates an application/x-jsonlines Blob to trigger a silent, immediate HTML download.

jsPDF & jsPDF-AutoTable (Document Generation): For the CSV to PDF tool, PapaParse extracts the headers and rows, and hands them off to jsPDF. It calculates landscape orientations and uses autoTable to draw clean, formatted grids entirely in the user's RAM.

Native Image APIs (Image to PDF): Instead of a heavy library, the app reads image files via FileReader, loads them into a native HTML5 Image object to calculate aspect ratios dynamically, and draws them onto a PDF canvas with a calculated padding scale.

The Routing Architecture (Keeping the Bundle Small)

When you have 15+ completely different tools (SVG optimizers, Markdown parsers using marked, Base64 encoders), bundling them all together would create a massive, slow-loading JavaScript file.

Instead of hardcoding every route, the app uses a dynamic routing engine built on React Router v7.
I created a central tools.ts configuration array. Every tool component is wrapped in React.lazy and a fallback.

// The routing map automatically generates URLs and lazy-loads the heavy libraries only when clicked
{TOOLS_CONFIG.map((tool) => (
  <Route
    key={tool.id}
    path={tool.path}
    element={
      <Suspense fallback={<ToolLoadingFallback />}>
        <SeoHead title={tool.name} slug={tool.path} />
        <tool.component />
      </Suspense>
    }
  />
))}

If a user only wants to encode Base64, their browser never downloads the heavy jsPDF or mammoth (Word doc parsing) libraries.

The Lessons Learned

The Main Thread Trap:
When a user drops a massive 50MB CSV file into the Shadcn dropzone, PapaParse has to chew through millions of lines. Because JavaScript is single-threaded, doing this directly on the main thread freezes the entire React UI. The browser looks like it crashed. To fix this, heavy conversions must be pushed to Web Workers, letting the UI thread keep the loading spinners running smoothly.
Client-Side Word Documents are a Nightmare:
Extracting raw text from a .docx file using mammoth.js works decently, but attempting to preserve complex tables, proprietary fonts, and exact margins to render directly into a PDF purely on the client side is an absolute nightmare compared to doing it in a Python backend.

The Ask

I am currently trying to optimize the Word to PDF conversion pipeline. mammoth is great for raw HTML extraction, but getting jsPDF to map that HTML back into a perfectly formatted, paginated PDF without a backend rendering engine is proving difficult.

If anyone has successfully built a robust DOCX to PDF pipeline that runs 100% in the browser (without using an API like CloudConvert), I would love to hear how you handled the layout rendering.