DEV Community: Vladimir PPC

How I Built an NDA-Safe CSV to Markdown Converter (100% Client-Side)

Vladimir PPC — Wed, 29 Jul 2026 15:05:22 +0000

If you write documentation on GitHub, GitLab, or use Obsidian, you deal with Markdown tables. And you know they are a pain to write by hand.

The Hack

Aligning pipes (|), escaping special characters, and maintaining readability in plain text is tedious. The usual shortcut is to copy data from Excel or a CSV file, paste it into a free online converter, and grab the markdown output.

But here is the massive problem: where does that pasted data go?

Most of these tools process data on a backend server. If you are pasting internal company analytics, financial data, or API schemas, you are transmitting sensitive information to a third party. If your company requires you to sign an NDA, using these online converters is a direct violation of data privacy policies.

I needed a solution that was fast, easily accessible, and, most importantly, 100% local. Since I couldn't find a tool that checked all the boxes without requiring a CLI environment, I built CSV to Markdown (.md) — a Chrome extension that does the conversion entirely in your browser.

The Tech Stack

I wanted this to be extremely fast and lightweight. No heavy frameworks.

Vanilla JavaScript (Zero build steps, pure performance)
Chrome Extensions API (Manifest V3)
PapaParse (For robust CSV parsing)
JSZip (For generating batch archives directly in memory)

Under the Hood (The Code)

The extension's primary job is mapping parsed CSV data into a Markdown table structure.

Once the data is parsed from the clipboard or an uploaded file, the core generation logic builds the headers and rows. Here is a simplified version of how the Markdown is generated:

const generateMarkdownTable = (parsedData) => {
  if (!parsedData || parsedData.length === 0) return '';

  const headers = parsedData[0];
  // Generate the separator row: |---|---|---|
  const separator = headers.map(() => '---').join(' | ');

  // Map rows and join them with pipes
  const rows = parsedData.map(row => row.join(' | '));

  return `${rows[0]}\n${separator}\n${rows.slice(1).join('\n')}`;
};

For batch processing, instead of converting a single string, the extension loops through an array of files, processes them, and packs them into a .zip file using JSZip, triggering a download without ever touching a server.

Security & Permissions

Because this tool is designed for developers working under NDAs, security was the primary focus.

The extension operates with zero network requests. You can open the Network tab in your DevTools, paste your data, and click convert — nothing is sent out. The extension only requires minimal permissions necessary to read clipboard data when the user explicitly clicks the paste button. Your data never leaves your machine.

Challenges

1. Complex CSV Parsing

Initially, I thought I could just parse the CSV by splitting strings by commas and newlines: text.split('\n').map(row => row.split(',')).
That broke immediately. What if a cell contains a comma? What if it has line breaks or escaped quotes? Writing a custom regex parser was fragile, so I integrated PapaParse, which handles all edge cases gracefully right in the browser.

2. Client-Side Batch Downloads

One of the PRO features is batch processing — dropping 20 CSV files and getting them back as Markdown. The challenge was forcing the browser to download a generated .zip file without a backend. I used JSZip to generate a Blob in memory, created a temporary <a> tag, set its href to a URL.createObjectURL(blob), and triggered a programmatic click to start the download.

Try it out & Contribute

The extension is available in the Chrome Web Store. The free version allows up to 5 conversions per day, which covers most daily documentation tasks.

Get CSV to Markdown from the Chrome Web Store

If you need unlimited batch processing (drag-and-drop multiple files) or smart column alignment, I offer a Lifetime PRO version via Gumroad.

If you find a bug, want to request a feature, or just want to explore the code, check out the repository. Contributions and issues are welcome!

GitHub Repository

Stop writing tables by hand and stop leaking your company's data to random websites. Keep it local.

Why Most PDF Readers Butcher Two-Column Text (And How I Fixed It With Spatial Parsing)

Vladimir PPC — Fri, 24 Jul 2026 10:27:58 +0000

If you've ever tried to use a Text-to-Speech (TTS) tool to listen to a research paper, you already know the pain. You upload an arXiv paper, hit play, and the voice starts reading:

"Introduction ... Abstract ... 1. Background ... We present a new methodology for ... the state of the art in ... "

It reads straight across the page, blindly mashing the left and right columns together into an incomprehensible word salad. Even expensive tools like Speechify or standard open-source options like Chrome's built-in Read Aloud suffer from this.

I got frustrated enough that I spent a weekend building my own solution: a Chrome Extension called Read PDF Aloud. The goal was simple: properly parse two-column PDFs and read them entirely offline for privacy. Here is how I built it.

The Tech Stack

I wanted this to be a lightweight client-side tool. No backend, no cloud processing, no sending sensitive research or legal documents to a third-party server.

Manifest V3 Chrome Extension
PDF.js (Mozilla) – To extract text and exact positional coordinates.
Web Speech API – The browser's native speechSynthesis engine for 100% offline TTS.

Under the Hood: Spatial Parsing

Most PDF readers fail because they rely on the raw text extraction order from the PDF file. Instead of doing that, I used PDF.js to grab the bounding box (transform matrix) of every single text item on the page, and then applied spatial sorting.

First, we filter out headers and footers (top and bottom 7% of the page) so the TTS doesn't randomly read page numbers in the middle of a sentence:

const W = viewport.width;
const H = viewport.height;

// Exclude top 7% and bottom 7%
const contentItems = textContent.items.filter(item => {
  const ty = item.transform[5];
  return ty > H * 0.07 && ty < H * 0.93;
});

Next, we run a simple heuristic to detect if the page actually has a two-column layout. We count how many text blocks sit purely on the left half of the page, how many on the right, and how many cross the middle boundary.

let leftCount = 0;
let rightCount = 0;
let crossCount = 0;

contentItems.forEach(item => {
  const tx = item.transform[4];
  const w = item.width || 0;
  const mid = W * 0.5;

  if (tx + w < mid) leftCount++;
  else if (tx > mid) rightCount++;
  else crossCount++;
});

// If there are distinct left/right blocks and very few crossing the middle:
const isTwoColumn = leftCount > 5 && rightCount > 5 && (crossCount / contentItems.length) < 0.15;

If isTwoColumn is true, we partition the items into leftItems and rightItems, sort them separately by their Y-coordinate (top to bottom), and then append the right column to the end of the left column. Suddenly, research papers read perfectly in order!

The Challenge: Table Cells and Missing Pauses

One major issue I hit was data tables. When you have a table row like A-10 15 4.2%, the Web Speech API reads it as a single rushed sentence ("Atenfifteenfourpointtwo...").

Since PDF.js just gives us raw text chunks, I had to calculate the horizontal gap between words. If the gap is unusually large, we inject a hidden comma. The Web Speech API naturally pauses on commas, which creates a perfect, structured reading flow for tables!

// PDF.js item.width can sometimes be inflated by trailing spaces. 
// We use an estimated width for safety.
const estimatedWidth = lastStr.trim().length * minHeight * 0.45;
const effectiveWidth = Math.min(lastWidth, estimatedWidth);
const xGap = tx - (lastX + effectiveWidth);

if (xGap > minHeight * 0.8) {
  // Inject a comma to force the TTS engine to pause between table cells!
  pageText += ", \u2003\u2003 "; 
} else if (pageText.length > 0 && !pageText.endsWith("\n") && !pageText.endsWith(" ")) {
  pageText += " ";
}

Security & Permissions

Because this is aimed at academics, analysts, and lawyers who read confidential documents, privacy was non-negotiable.

By handling all the parsing locally via PDF.js and pushing the text directly to the native window.speechSynthesis, the extension requires exactly zero external HTTP requests. No API keys, no server costs, and the permissions in manifest.json are kept strictly to local storage and active tab execution.

The Result

Building this taught me a lot about the quirks of PDF structures. If you deal with two-column PDFs or just want an offline bimodal reader (it highlights sentences and words as it speaks), you can check out the result on the Chrome Web Store: Read PDF Aloud: PDF Text to Speech & Voice Reader.

Have you ever tried parsing PDFs in JS? Let me know in the comments if you've found better ways to handle mixed layouts (like tables spanning across columns).

From Raw SVG to Production JSX: DOMParser, TypeScript, and Manifest V3

Vladimir PPC — Sun, 12 Jul 2026 11:28:28 +0000

Forty-two minutes. That’s the context-switch tax I lost last Tuesday wrestling a single navigation icon. I dropped a raw Figma export into VS Code, immediately hit the JSX friction wall: class instead of className, hyphenated attributes triggering ESLint, and legacy xlink:href tags throwing the TSX compiler into a syntax error. I manually renamed props, wrapped it in a functional component, and wrote type definitions. By the time I finished, my flow was dead.

This isn't an edge case; it's a daily grind. I tried cloud-based converters. They're slow, stuffed with third-party telemetry, and I'm absolutely not feeding unreleased design assets to a remote subdomain. I even spun up a Node script with SVGR's CLI. It handled clean exports fine, then immediately choked on a complex Illustrator file. Mixed XML namespaces and nested layer groups broke the AST parser. I needed instant, deterministic, offline processing.

The Core Engine: DOMParser & Attribute Mapping

I architected this as a Chrome Extension running entirely under Manifest V3. The transformation pipeline relies on the native DOMParser API, executing synchronously in an isolated background context. I pipe the raw SVG string, traverse the DOM tree, and apply a strict dictionary for camelCase conversions.

Here’s the conceptual mapping logic:

const parser = new DOMParser();
const doc = parser.parseFromString(svgString, "image/svg+xml");

const ATTR_MAP = {
  class: 'className',
  'stroke-width': 'strokeWidth',
  'fill-rule': 'fillRule',
  'stroke-linecap': 'strokeLinecap'
};

function mapAttributes(node) {
  Array.from(node.attributes).forEach(attr => {
    const targetName = ATTR_MAP[attr.name] || attr.name.replace(/-([a-z])/g, (_, char) => char.toUpperCase());
    if (targetName !== attr.name) {
      node.removeAttribute(attr.name);
      node.setAttribute(targetName, attr.value);
    }
  });
  Array.from(node.children).forEach(mapAttributes);
}

The Namespace Crash & JSX Resolution

DOMParser handles raw XML fine, but browsers play fast and loose with XML namespaces. React’s JSX compiler does not. My initial build crashed the minute I dropped in an animated chart SVG. It packed xmlns:xlink declarations and inline <use> tags referencing xlink:href. Modern browsers parse this silently, but when serialized to JSX, the unparsed namespace prefixes and deprecated attributes throw immediate syntax errors during the tsdx/esbuild transpilation step.

I had to implement a recursive cleanup pass before serialization:

Namespace Stripping: Explicitly walk the tree, detect xmlns:xlink, and drop the attribute declaration from the root.
Legacy Migration: Query all <use> and <a> tags. Copy the xlink:href value to a standard href attribute, then safely delete xlink:href.
Security Hardening: Explicitly block and sanitize <script>, <foreignObject>, and inline event handlers (onload, onclick) during traversal. This forces the pipeline to strictly output declarative, safe markup.

Once the attribute resolver locked in, the transformer became fully synchronous.

Security: Manifest V3 Sandbox & Zero Network Requests

Because this runs under Manifest V3, the entire pipeline executes in a strictly sandboxed background service worker. There are zero fetch calls, zero CDN dependencies, and absolutely no external server routing. Every transformation happens clientside in memory. If your design files contain proprietary dashboard UI logic, they never leave the local machine. The isolated execution model guarantees deterministic output without telemetry or external payload validation.

Production Workflow & TypeScript Integration

I wired the workflow to Alt+S. Hit the shortcut, paste the markup, or drag a .svg directly into the popup. You get clean JSX in under 200ms. Handling edge cases manually got tedious, so I baked in the production features I actually use:

Batch Processing: Drop dozens of icons, output a single bundled .ts file or a structured .zip.
React Hydration: Auto-wraps exports in React.memo, injects forwardRef so tooltip/popover libraries don't panic, and swaps hardcoded hex values to currentColor for seamless CSS variable overrides.
Strict TypeScript: Bakes in React.SVGProps<SVGSVGElement> definitions out of the box. The compiler stays quiet, and IntelliSense works immediately.

Shipping it brought the usual infra headaches. I wired up chrome.i18n from day one, shipping RU, EN, DE, ES, FR, PT, ZH, and JA. It felt like overhead until download velocity spiked from Germany and Japan. For licensing, I initially tried Lemon Squeezy but hit domain verification walls. Migrated to Gumroad, skipped the compliance queue, and shipped a lifetime access checkout. It killed 2 AM support tickets and simplified the revenue pipeline.

Conclusion

Developers don't hate configuration; we hate losing flow. Tools that demand logins, network handshakes, and confirmation modals break context. Local execution isn't a technical flex—it's the baseline for serious engineering workflows. I built this to stop bleeding time on Figma exports while deadlines loomed. Turns out, the friction was universal.

If you want to cut the manual cleanup tax and process SVGs entirely offline, you can grab the extension here:

https://chromewebstore.google.com/detail/pjadcdedmjliokpjfcholckcnkaheobc?utm_source=devto&utm_medium=article&utm_campaign=svg_to_react_launch

Drop a comment if you're running into specific namespace edge cases or have ideas for the next AST traversal pass.