DEV Community: Aftan Ahmad

I Built a Tool to Turn Messy Bank Statement PDFs Into Spreadsheets

Aftan Ahmad — Sat, 03 Oct 2026 14:00:25 +0000

I Built a Browser-Based PDF Bank Statement Parser

I recently built and launched SheetParse, a browser-based tool that converts bank statement PDFs into spreadsheet-ready data.

https://sheetparse.com

The idea started with a simple problem: PDF is a great format for reading a bank statement, but it's a pretty terrible format when you actually want to work with the transaction data.

If you need to analyze, filter, reconcile, or move the transactions into Excel, you quickly end up dealing with manual copy-pasting or unreliable PDF converters.

So I decided to build my own solution.

The interesting part: bank statements aren't standardized

At first, I thought the problem would basically be:

PDF → Extract text → Parse transactions → Excel

It turned out to be much messier.

Different banks use completely different layouts.

Some have separate debit and credit columns. Others combine them. Transaction descriptions can span multiple lines. Headers and footers can appear between transactions. Some PDFs contain actual text, while others are essentially scanned images.

So the actual pipeline looks more like:

PDF
 ↓
Text extraction / OCR
 ↓
Statement detection
 ↓
Bank-specific parsing
 ↓
Transaction normalization
 ↓
Validation
 ↓
CSV / XLSX

I decided to process everything locally

One of the main decisions I made was to keep document processing in the browser whenever possible.

Bank statements contain sensitive financial information, so I didn't particularly like the idea of requiring users to upload their documents to a random server just to convert them.

With SheetParse, the document can be processed locally in the browser.

That also means I don't need a large backend infrastructure just to process someone's PDF.

Bank-specific parsers

Another thing I learned is that trying to create one universal parser isn't necessarily the best approach.

Instead, SheetParse has parsers designed around different statement formats, along with a generic parser for unsupported formats.

The goal is to normalize everything into a consistent structure such as:

Date
Description
Debit
Credit
Balance

Once the data is normalized, generating CSV or XLSX becomes much easier.

OCR is a different problem

Text-based PDFs and scanned PDFs are very different.

If a PDF contains actual text, extraction is relatively straightforward.

But if every page is essentially an image, there isn't any transaction text to extract.

That's where OCR becomes useful.

SheetParse uses OCR as a fallback for these types of documents.

The tradeoff is that OCR is slower and can introduce additional ambiguity, especially with things like numbers, dates and transaction descriptions.

Extraction isn't enough

One of the biggest things I learned while building this is that extracting rows isn't the same as extracting correct data.

For financial documents, an incorrect transaction can be worse than a missing transaction because it can silently affect someone's calculations.

So validation becomes important.

Things like:

duplicate transactions
broken dates
incorrect debit/credit values
transactions split across lines
repeated headers
page boundaries
running balances

all need to be considered.

The parser needs to understand the structure of the statement rather than simply grabbing everything that looks like a row.

Column Studio

I also wanted SheetParse to do more than simply extract the transactions and immediately export them.

That's why I built Column Studio in SheetParse.

After the data has been extracted, Column Studio lets you work with the resulting columns before exporting the final spreadsheet.

Instead of having to take the raw output into another tool just to make small changes, you can prepare the dataset within SheetParse itself.

The idea is to make the workflow closer to:

PDF
↓
Extract
↓
Clean / organize columns
↓
Review
↓
Export

This became particularly useful because different people want different spreadsheet structures.

Someone might only need:

Date | Description | Amount

while another workflow might need:

Date | Description | Debit | Credit | Balance

Rather than forcing one output format on everyone, Column Studio gives the user more control over the extracted dataset.

Why build it in the browser?

There were a few reasons.

Privacy

The document doesn't have to be uploaded to a backend just for parsing.

Infrastructure

There isn't a document-processing server running for every conversion.

Simplicity

The application can remain relatively lightweight.

Cost

Client-side processing reduces the infrastructure required to operate the service.

There are obviously tradeoffs too. Large PDFs and OCR can consume significant CPU and memory in the browser, so performance is something I'm continuing to work on.

What I learned

The biggest lesson wasn't really about PDF parsing.

It was that real-world documents are messy.

A parser can work perfectly against ten sample PDFs and then encounter a completely different layout in the eleventh.

That's why supporting more banks isn't simply a matter of adding another parser. Each format needs representative documents, edge cases and regression tests.

I'm now much more interested in the reliability and validation side of document processing than I was when I started the project.

SheetParse is live

The first public version is now available:

https://sheetparse.com

It currently supports multiple bank statement formats, a generic parser, and OCR fallback for scanned PDFs.

It's still an early project, but it's something I've wanted to build for a while, and it's finally out in the wild.

If you've worked with PDF parsing, OCR, financial data extraction, or document processing, I'd be interested to hear how you've approached similar problems.

What are some of the weirdest PDF formats you've had to deal with?

Why Your JSON Tools Freeze (And How We Fixed It with Web Workers)

Aftan Ahmad — Fri, 07 Aug 2026 14:01:20 +0000

If you’ve ever pasted a 15MB JSON file into a browser-based formatter, you’ve likely seen it: the screen freezes, typing lags, the browser throws an "Aw, Snap!" error, or the fan spins up like a jet engine.

The culprit isn't JavaScript being slow—it’s blocking the UI thread.

When you run JSON.parse(), complex regex replacements, or type generation on the main thread, you block rendering, user inputs, and animations.

In this article, we’ll look at how we built MyJSONPal—a client-side JSON and data studio—to process multi-megabyte payloads instantly without freezing the browser using React 19, CodeMirror 6, and Web Workers.

The Solution: Off-Main-Thread Processing

To keep the editor buttery smooth, we need to offload heavy computation to a background thread using a Web Worker.

[ Main Thread ] ----> postMessage(JSON) ----> [ Web Worker ]

CodeMirror / UI                               AST Auto-Fix / Conversions
      │                                                │
      └────────── Receive Output Back ────────────────┘

By decoupling computation from rendering:

The editor remains interactive at 60 FPS while background work happens.
Heavy processing never blocks typing or scrolling.
Large payloads are processed in parallel with the UI lifecycle.

Step-by-Step Architecture

1. Define a Unified Processing Contract

To keep workers predictable and type-safe, create a shared contract for all inputs and outputs.

// types.ts

export type TargetFormat =
  | 'json'
  | 'csv'
  | 'yaml'
  | 'typescript'
  | 'zod'
  | 'sql';

export interface TaskInput {
  action: 'format' | 'minify' | 'fix' | 'convert';
  code: string;
  targetFormat?: TargetFormat;
  indentation?: number;
}

export interface TaskResult {
  success: boolean;
  output: string;
  error?: {
    message: string;
    line?: number;
    column?: number;
  };
  metrics?: {
    originalBytes: number;
    outputBytes: number;
    timeMs: number;
  };
}

2. Create the Worker Task Processor

Inside worker.ts, listen for incoming messages, execute pure processing logic, and return the result.

// worker.ts

import { processJsonPayload } from './jsonProcessor';
import type { TaskInput } from './types';

self.onmessage = (event: MessageEvent<TaskInput>) => {
  const startTime = performance.now();

  try {
    const result = processJsonPayload(event.data);
    const endTime = performance.now();

    self.postMessage({
      ...result,
      metrics: {
        ...result.metrics,
        timeMs: Math.round(endTime - startTime),
      },
    });
  } catch (err: any) {
    self.postMessage({
      success: false,
      output: '',
      error: {
        message: err.message || 'Processing failed',
      },
    });
  }
};

3. Build a Worker Client with Fallback Support

Not every environment handles Web Workers the same way. For example:

Server-side rendering (SSR)
Embedded webviews
Restricted browser environments

Always provide a fallback path.

// workerClient.ts

import type { TaskInput, TaskResult } from './types';

let workerInstance: Worker | null = null;

function getWorker(): Worker | null {
  if (typeof window === 'undefined') return null;

  if (!workerInstance && window.Worker) {
    workerInstance = new Worker(
      new URL('./worker.ts', import.meta.url),
      {
        type: 'module',
      }
    );
  }

  return workerInstance;
}

export async function executeTask(
  input: TaskInput
): Promise<TaskResult> {
  const worker = getWorker();

  // Primary path: execute off-main-thread
  if (worker) {
    return new Promise((resolve) => {
      worker.onmessage = (e: MessageEvent<TaskResult>) =>
        resolve(e.data);

      worker.postMessage(input);
    });
  }

  // Fallback path: lazy-load on main thread
  const { processJsonPayload } = await import('./jsonProcessor');

  return processJsonPayload(input);
}

4. Connect It to React & CodeMirror 6

Now wire asynchronous processing into your editor using debouncing to avoid flooding worker threads on every keystroke.

// EditorWorkspace.tsx

import React, {
  useState,
  useEffect,
  useCallback,
} from 'react';

import { executeTask } from './workerClient';

export const EditorWorkspace = () => {
  const [inputCode, setInputCode] = useState('');
  const [outputCode, setOutputCode] = useState('');
  const [isProcessing, setIsProcessing] = useState(false);

  const handleTransform = useCallback(async (code: string) => {
    if (!code.trim()) return;

    setIsProcessing(true);

    const result = await executeTask({
      action: 'convert',
      code,
      targetFormat: 'typescript',
    });

    if (result.success) {
      setOutputCode(result.output);
    } else {
      console.error(result.error?.message);
    }

    setIsProcessing(false);
  }, []);

  useEffect(() => {
    const timer = setTimeout(() => {
      handleTransform(inputCode);
    }, 150);

    return () => clearTimeout(timer);
  }, [inputCode, handleTransform]);

  return (
    <div className="grid grid-cols-2 gap-4">
      <textarea
        value={inputCode}
        onChange={(e) => setInputCode(e.target.value)}
        placeholder="Paste JSON here..."
      />

      <div className="relative">
        {isProcessing && (
          <div className="absolute top-2 right-2 text-xs">
            Processing...
          </div>
        )}

        <pre>{outputCode}</pre>
      </div>
    </div>
  );
};

Bonus: The "Magic" Auto-Repair Pattern

Moving processing into a worker unlocks CPU budget for automatic JSON repair without affecting UI responsiveness.

For example, you can handle:

Trailing commas
Single quotes
JavaScript comments
Python literals (True, False, None)
Unquoted object keys

// jsonFixer.ts

export function repairJson(dirtyJson: string): string {
  return dirtyJson
    // Remove UTF-8 BOM
    .replace(/^\uFEFF/, '')

    // Replace Python/JS literals
    .replace(/:\s*True\b/g, ': true')
    .replace(/:\s*False\b/g, ': false')
    .replace(/:\s*None\b/g, ': null')

    // Remove JS comments
    .replace(
      /\/\*[\s\S]*?\*\/|([^\\:]|^)\/\/.*$/gm,
      '$1'
    )

    // Fix unquoted keys
    .replace(
      /([{,]\s*)([a-zA-Z0-9_]+?)\s*:/g,
      '$1"$2":'
    )

    // Convert single quotes
    .replace(
      /'([^'\\]*(\\.[^'\\]*)*)'/g,
      '"$1"'
    )

    // Remove trailing commas
    .replace(/,\s*([}\]])/g, '$1');
}

Because this logic runs inside a worker, even large malformed files can be repaired without causing frame drops or blocking the UI.

Results & Takeaways

By moving payload processing, AST repair, and type generation into a Web Worker architecture, we achieved three major improvements:

🚀 Zero Thread Blocking

Typing, scrolling, and editor interactions remain smooth at 60 FPS, regardless of JSON file size.

🔒 True Data Privacy

All processing happens entirely in the browser. No payloads are uploaded, stored, or transmitted to remote servers.

⚡ Instant Feedback

Even large datasets can be transformed in under 20ms without freezing the browser.

Try It Yourself

You can try this exact architecture in production with MyJSONPal — a free, privacy-first JSON studio built with:

Astro
React 19
CodeMirror 6
Tailwind CSS v4
Web Workers

Final Thoughts

Web Workers aren't just an optimization anymore—they're a requirement for modern browser-based developer tools handling large datasets.

If your users are working with multi-megabyte files, schema generation, AST transforms, or code conversion, moving heavy processing off the main thread is one of the highest-impact performance improvements you can make.

How are you handling heavy processing in your client-side applications? Let me know in the comments 👇

I got tired of online JSON tools crashing on syntax errors and conversions, so I built a local-first repair engine

Aftan Ahmad — Sat, 01 Aug 2026 15:52:52 +0000

Every developer uses online JSON formatters daily to debug API responses, inspect log files, or check database dumps.

But standard JSON formatters come with two recurring papercuts:

Parser Fragility: Standard JSON.parse is unforgiving. A single trailing comma, missing quote, or Python-style True/False boolean completely crashes the formatter, forcing you to fix it manually character by character.
Data Privacy Risks: Pasting production payloads, JWTs, or environment variables onto unencrypted, third-party server-side formatters is a security risk waiting to happen.

To solve both issues for my own workflow, I built MyJSONPal—a 100% client-side JSON studio designed for speed, privacy, and auto-repair.

⚡ 1. Magic AST Auto-Repair

Instead of failing on malformed JSON, MyJSONPal uses a client-side parsing engine that automatically cleans common syntax issues before formatting:

Trailing Commas: Strips trailing commas from arrays and objects.
Quote Normalization: Converts single-quoted strings and unquoted object keys into valid double-quoted JSON.
Language Equivalents: Automatically normalizes Python booleans (True/False) and None values into standard JSON syntax (true/false/null).

🔒 2. 100% In-Browser Privacy

Security shouldn't be an afterthought when inspecting API responses.

MyJSONPal runs entirely in your browser. There are zero server network calls, zero tracking logs, and zero remote data stores. Your production payloads and tokens never leave your local machine.

🛡️ 3. One-Click Type & Schema Generation

When integrating APIs, formatting the JSON is only step one. You usually need type definitions next.

MyJSONPal instantly infers:

Zod Schemas: Generates ready-to-use z.infer schemas for immediate runtime validation.
TypeScript Interfaces: Converts raw payloads into clean TS types.
Data Exports: Converts JSON directly to CSV (RFC 4180 compliant) and YAML.

Additional Core Features

Beyond the AST Auto-Repair, Client-Side Privacy, and Type Generation already covered, here are the additional core features built into MyJSONPal that make it a complete JSON workbench.

1. Advanced Structural Transformations

Recursive Key Sorting
- Instantly sorts all keys in nested objects alphabetically (A–Z or Z–A) to standardize payloads before committing or comparing.
Smart Minification & Formatting
- Switch between minifying payloads into a single line for API calls or formatting them with customizable tab or space indentation.
Key Extraction & Dot-Notation
- Flatten complex nested structures and extract all keys along with their precise dot-notation paths (e.g., user.profile.settings.theme).

2. Deep Data Conversion Pipeline

Bi-directional Conversions
- Convert JSON seamlessly into YAML, CSV (RFC 4180), or XML, and vice versa.
Base64 & Stringify Tools
- Decode Base64 payloads (such as JWTs) directly into structured JSON, or escape raw JSON into stringified literals ready for use in code variables.

3. Visual Exploration & Search

Interactive Collapsible Tree View
- Navigate massive multi-megabyte payloads with expandable and collapsible nodes, making it easy to inspect deeply nested responses.
Live Search & Path Finder
- Search for specific keys, values, or array indices across large datasets without slowing down the editor.

4. Performance & UX Foundations

Web Worker Architecture
- Heavy processing runs inside isolated background threads, keeping the UI responsive even when working with large database exports.
Shared Workspace State
- Paste your JSON once and switch between validators, converters, and generators without losing your input or re-uploading files.
VsCode Styled Editor
- Enjoy syntax highlighting, error-line navigation, dark/light theme support, and offline-first functionality.

🚀 Try It Out

It's completely free to use with no account required:

👉 myjsonpal.com

I’d love to hear your feedback! What JSON edge cases or converter options would make your daily debugging workflow easier? Let me know in the comments below!