Forem: KAAN TOKALI

I Built Two Browser Tools That Developers Actually Need — No Upload, No Backend, No BS

KAAN TOKALI — Fri, 24 Apr 2026 06:54:10 +0000

Cross-posted from omnvert.com — a growing collection of free, privacy-first web tools.

I got tired of the same experience every time I needed a quick file conversion:

Google "heic to jpg online" or "csv to json converter"
Land on a site with 14 ads, a file size limit, and a spinner that uploads my file to god-knows-where
Wait. Wonder if my data is now on some server in a basement somewhere.
Download the result.

So I built two tools into Omnvert that do this differently: everything runs in your browser, nothing touches a server, and the tools are fast enough that you barely notice the conversion happened.

Here's what I built, why, and the interesting technical parts.

Tool 1: HEIC → JPG / PNG Converter

The problem

Apple switched iPhones to HEIC format back in iOS 11 (2017). It's genuinely better than JPEG — similar visual quality, roughly half the file size. The problem is that the rest of the world never got the memo.

Try to upload a photo from your iPhone to:

A web form
Figma
Google Slides
Most CMS platforms
Windows Photo Viewer (without a codec pack)

Most of them either reject the file silently or show a broken image icon. So every iPhone user periodically needs to convert HEIC to JPG, and most of the tools for this upload your photos to a server.

The irony: HEIC files often contain your GPS location, device information, and timestamps in their EXIF metadata. These are exactly the kind of files you don't want to upload to a random server.

The solution

The tool uses heic2any, a library that decodes HEIC using WebAssembly in the browser. No server involved.

import heic2any from 'heic2any';

const converted = await heic2any({
  blob: heicFile,
  toType: 'image/jpeg',
  quality: 0.85
});

That's the core of it. The rest is UX: batch processing, progress indicators per file, before/after file size display, and ZIP download for multiple files using JSZip.

One thing that surprised me

HEIC decoding is slow. Not "annoying" slow — I mean 1–3 seconds per image in the browser. HEIC uses HEVC compression, which is computationally expensive to decode. The WASM runtime handles it but it's doing real work.

This means the UX needs to communicate progress clearly. A spinner that runs for 2 seconds feels like a frozen app. A per-file progress bar that says "Converting image 3 of 7..." feels fast, even if it takes the same time.

The iOS Safari quirk

The ironic part of building a HEIC converter: the people who most need it are iPhone users, and iOS Safari has its own opinions about file inputs. Testing on actual iOS Safari was essential — the file picker behavior for .heic files is slightly different from desktop Chrome, and getting tap-to-upload working correctly took a few iterations.

Try it: omnvert.com/en/tools/heic-to-jpg

Tool 2: CSV ↔ JSON Converter

The problem

This one comes up constantly in development work. You have:

A CSV export from a database, analytics platform, or spreadsheet
You need it as JSON for an API, config file, or JavaScript import
Or the reverse — a JSON array from an API that needs to go into a spreadsheet

The manual process is either "write a script real quick" (which takes longer than it should) or use an online tool that uploads your data somewhere.

The "upload your data" part is a real problem when the CSV contains user emails, internal analytics, or anything you wouldn't want on a stranger's server.

What the tool does

It's bidirectional. Two tabs: CSV → JSON and JSON → CSV.

CSV → JSON gives you options:

Input CSV:
name,age,active
Alice,30,true
Bob,25,false

Output (array of objects):
[
  { "name": "Alice", "age": 30, "active": true },
  { "name": "Bob", "age": 25, "active": false }
]

The type inference feature is the one I find most useful. Without it, everything comes out as strings — "age": "30" instead of "age": 30. With it enabled, numbers become numbers, booleans become booleans, and empty/null values become actual null.

JSON → CSV handles the annoying edge cases:

Nested objects are a common pain point. If your JSON looks like:

[
  { "name": "Alice", "address": { "city": "Istanbul", "country": "TR" } }
]

The tool flattens it to dot notation:

name,address.city,address.country
Alice,Istanbul,TR

Not perfect for deeply nested structures, but it handles the one-level nesting that covers probably 80% of real-world cases.

Delimiter auto-detection handles the European vs. American CSV difference. European Excel exports often use semicolons instead of commas (because commas are decimal separators in many European number formats). The tool detects comma, semicolon, and tab automatically, or you can force a specific delimiter.

The library

The heavy lifting is done by PapaParse, which is genuinely excellent. It handles edge cases in CSV parsing that you really don't want to implement yourself — quoted fields with commas inside them, newlines inside quoted fields, BOM characters, inconsistent line endings.

import Papa from 'papaparse';

// CSV → JSON
const result = Papa.parse(csvString, {
  header: true,
  skipEmptyLines: true,
  dynamicTyping: typeInferenceEnabled
});

// JSON → CSV
const csv = Papa.unparse(jsonArray, {
  delimiter: selectedDelimiter
});

dynamicTyping: true is PapaParse's built-in type inference. When it's on, it handles numbers and booleans automatically. The custom inferType function I added handles the null/NULL/empty string → null cases that PapaParse doesn't cover.

Live conversion

The output updates as you type, debounced at 300ms. This makes the tool feel like a REPL rather than a form you submit. For large files (above ~500KB), there's a warning since live conversion can get sluggish — but you can still trigger it manually with Ctrl+Enter / Cmd+Enter.

Try it: omnvert.com/en/developer-tools/csv-json

The privacy angle

Both tools share the same philosophy: your files never leave your device.

This isn't a marketing claim — it's the architecture. There's no backend endpoint receiving files. The conversion code runs in your browser using JavaScript and WebAssembly. You can open DevTools → Network tab while using either tool and watch: zero file upload requests.

For HEIC files this matters because they contain EXIF data including GPS coordinates. For CSV files this matters because they often contain user data, internal metrics, or anything else you'd rather not upload to an unknown server.

The privacy note on both tool pages is honest about what this means: it also means there's a file size ceiling (browser memory limits) and conversion speed depends on your device, not a server.

What's next

Omnvert has about 80 tools across image processing, PDF manipulation, network diagnostics, and developer utilities. The two tools above were the most requested additions based on what people were searching for and not finding as clean browser-based solutions.

If you run into edge cases, the feedback button on each tool page goes directly to me.

Both tools are free, require no signup, and work in any modern browser. Built with Next.js, PapaParse, heic2any, and a lot of testing on iOS Safari.

omnvert.com — Free tools for developers and everyday use.

Tags: #webdev #javascript #tools #opensource

From PNG to 3D Print: Building a Browser-Based STL Pipeline

KAAN TOKALI — Mon, 20 Apr 2026 21:21:14 +0000

If you've ever tried to 3D print a logo, a QR code, or a flat illustration, you know the usual pain: open Fusion 360 or Blender, trace the outlines, extrude, export, pray the mesh is manifold. It's a 30-minute detour for what should be a 30-second task.

Over the last few months, I've been building a set of browser-based tools that collapse this entire workflow into three clicks: upload image, pick thickness, download STL. No installs. No CAD knowledge. No server-side Python pipeline.

This post walks through the engineering behind that pipeline — the algorithms, the edge cases, and the browser-specific constraints that shaped every decision. If you're building geometry tools for the web, or you're just curious how raster-to-mesh conversion actually works, this one's for you.

Why Browser-Based Matters (And Why It's Hard)

Most 3D conversion tools are either desktop apps (Blender, Meshmixer) or server-side services where you upload a file, wait for a worker to process it, then download the result. Both have problems:

Desktop apps require installs, have steep learning curves, and don't fit into quick workflows.
Server-side services process your files on someone else's infrastructure. For designers handling client work, that's a privacy non-starter.

Browser-based processing solves both — but it comes with constraints that shape every architectural decision:

No filesystem access. You work with File objects, Blobs, and ArrayBuffers.
Memory ceilings. Mobile Safari will kill your tab around 300–400 MB. Even desktop Chrome gets unhappy past 1.5 GB.
Single-threaded by default. Any heavy computation blocks the UI unless you push it to a Web Worker.
No native mesh libraries. You're either writing your own geometry code or wrapping WebAssembly builds of C++ libraries.

With those constraints in mind, let's look at the three conversion problems I solved and how each one informed the pipeline.

Problem 1: Flat Image → 3D Extrusion

The simplest case. You have a PNG with transparency (say, a logo), and you want it as a printable relief. The algorithm is straightforward in theory:

Decode the image into a pixel array.
Threshold the alpha channel to get a binary mask.
Trace the boundary of the mask using marching squares.
Triangulate the polygon.
Extrude the 2D triangulation by a chosen thickness.
Cap the top and bottom with matching triangles.
Serialize as STL.

Here's the skeleton of the boundary extraction:

function extractBoundary(imageData, alphaThreshold = 128) {
  const { width, height, data } = imageData;
  const mask = new Uint8Array(width * height);

  for (let i = 0; i < width * height; i++) {
    mask[i] = data[i * 4 + 3] >= alphaThreshold ? 1 : 0;
  }

  const contours = [];
  const visited = new Uint8Array(width * height);

  for (let y = 0; y < height - 1; y++) {
    for (let x = 0; x < width - 1; x++) {
      if (visited[y * width + x]) continue;
      const code = marchingSquaresCase(mask, x, y, width);
      if (code === 0 || code === 15) continue;
      const contour = traceContour(mask, x, y, width, height, visited);
      if (contour.length > 3) contours.push(contour);
    }
  }

  return contours;
}

Marching squares gives you closed polygons. To mesh them into triangles, I use earcut — a fast ear-clipping triangulator from Mapbox that handles holes (for example, the inside of a letter "O" or "A"):

import earcut from 'earcut';

function triangulatePolygon(outerRing, holes = []) {
  const vertices = [...outerRing.flat()];
  const holeIndices = [];

  holes.forEach(hole => {
    holeIndices.push(vertices.length / 2);
    vertices.push(...hole.flat());
  });

  return earcut(vertices, holeIndices, 2);
}

Once you have a 2D triangulation, extrusion is almost trivial. For each 2D triangle, you create two copies at z = 0 and z = thickness. For each edge on the boundary polygon, you create two side-wall triangles. The result is a watertight mesh.

The ugly surprise: winding order. If your top and bottom faces have the same winding, your normals point inward on one side and your slicer will reject the mesh. Flip the bottom face's winding before writing.

I packaged this whole pipeline as a free tool if you want to see the output for your own images: PNG/SVG to STL converter. It handles alpha-masked PNGs and SVG paths in the same pipeline.

Problem 2: QR Codes → Printable 3D Models

QR codes look like a subset of the PNG case, but they're not. A 33×33 QR code has somewhere around 500+ "on" modules, and naive marching squares gives you 500+ disconnected polygons with horrible triangulation.

The right abstraction is to treat modules as unit squares and emit geometry directly:

function qrToMesh(matrix, moduleSize, baseThickness, codeHeight) {
  const vertices = [];
  const triangles = [];
  const size = matrix.length * moduleSize;

  emitBox(vertices, triangles, 0, 0, 0, size, size, baseThickness);

  for (let row = 0; row < matrix.length; row++) {
    for (let col = 0; col < matrix[row].length; col++) {
      if (!matrix[row][col]) continue;
      const x = col * moduleSize;
      const y = (matrix.length - row - 1) * moduleSize;
      emitBox(
        vertices, triangles,
        x, y, baseThickness,
        moduleSize, moduleSize, codeHeight
      );
    }
  }

  return { vertices, triangles };
}

This is dramatically faster than marching squares and produces a cleaner mesh — and critically, it makes the QR code actually readable after printing, because adjacent "on" modules merge into contiguous raised regions.

One subtle detail: QR scanners need contrast, not just geometry. If you print the whole thing in one color, your phone won't read it. The two real approaches are multi-material (dual-extruder) or printing the raised modules in one color and pausing at the base layer height to swap filament. The STL should reflect that workflow — the base and the raised modules are logically separate even if they ship as one file.

If you want to skip all this and just generate printable QR codes, the tool is here: QR Code to STL generator. It outputs both STL and 3MF so you can use the 3MF version for pause-at-height color changes in PrusaSlicer or Bambu Studio.

Problem 3: Shrinking a 55 MB STL to 4 MB

This is the problem I spent the most time on. An STL from a high-resolution input can easily hit 50+ MB, which is:

Painful to upload to a slicer over a slow connection
Impossible to share over Discord/Slack (8 MB limit)
Wasteful, because 90% of the triangles describe flat regions that could be a single quad

The algorithm here is mesh decimation — specifically, quadric error metrics (QEM) decimation, introduced by Garland and Heckbert in 1997 and still the standard.

The intuition:

For each vertex, compute a 4×4 "error quadric" matrix that encodes how far the vertex can move before distorting the surrounding planes.
For each edge, compute the cost of collapsing it (merging its two endpoints into one vertex).
Repeatedly collapse the lowest-cost edge, updating quadrics, until you hit your target triangle count.

The implementation is heavy enough that I won't drop the whole thing here, but the core data structure is a priority queue of edges keyed by collapse cost:

class DecimationQueue {
  constructor(mesh) {
    this.heap = new MinHeap();
    this.quadrics = new Float64Array(mesh.vertexCount * 16);

    for (let f = 0; f < mesh.faceCount; f++) {
      const q = planeQuadric(mesh.face(f));
      addToVertex(this.quadrics, mesh.face(f).v0, q);
      addToVertex(this.quadrics, mesh.face(f).v1, q);
      addToVertex(this.quadrics, mesh.face(f).v2, q);
    }

    for (const edge of mesh.edges()) {
      const cost = computeCollapseCost(edge, this.quadrics);
      this.heap.push({ edge, cost });
    }
  }

  collapseNext() {
    const { edge } = this.heap.pop();
    const newVertex = optimalPosition(edge, this.quadrics);
    // Merge edge endpoints, update neighbors, recompute costs
  }
}

Two pragmatic lessons I learned the hard way:

Lesson 1: Run decimation in a Web Worker, always. A 50 MB STL has around 1M triangles. Reducing to 100K triangles takes about 4–8 seconds on a modern laptop. Doing that on the main thread will freeze your UI and trigger the "page unresponsive" banner.

Lesson 2: Preserve boundary edges. If you naively decimate, the outer silhouette of your model will wobble as edges collapse. For 3D printing this is fatal — dimensional accuracy matters. Tag all vertices that sit on a boundary (any edge shared by only one face) and assign them infinite collapse cost.

The production tool that wraps all of this is here: STL Size Reducer. You can feed it a 50 MB file, tell it "give me 4 MB", and it'll decimate to hit that target. Internally it does binary search on the triangle count until the output file size lands within ~5% of your target.

The Full Pipeline: Stitching It Together

For a typical logo keychain workflow — upload a company logo, extrude to 3mm, add a keyring hole — the whole pipeline runs in under a second in the browser, including the STL write. The decimation pass only kicks in if you fed it a high-resolution source.

The flow is:

Decode input (PNG, SVG, or QR matrix)
Vectorize into polygons (marching squares or SVG parse)
Triangulate with earcut
Extrude to 3D
Write binary STL
Optionally decimate if result is over 10 MB

If you want to inspect the resulting mesh before slicing, I also built an in-browser STL/OBJ/3MF viewer and a 3D model converter that handles STL, OBJ, GLB, 3MF, and PLY. Between those, the pipeline above, and the decimator, you can go from "I have a PNG" to "I have a sliced G-code" without installing a single desktop app.

Binary STL Writing: The One Thing Everyone Gets Wrong

A quick note because I've seen several browser STL exporters do this incorrectly: always write binary STL, not ASCII.

ASCII STL looks like this:

facet normal 0.0 0.0 1.0
  outer loop
    vertex 0.0 0.0 0.0
    vertex 1.0 0.0 0.0
    vertex 1.0 1.0 0.0
  endloop
endfacet

It's human-readable but around 5–7x larger than the binary equivalent. A 1M-triangle mesh that's 50 MB in binary becomes 280+ MB in ASCII. Your users will run out of browser memory before they can even download.

Binary STL is 84 bytes of header plus 50 bytes per triangle:

function writeBinarySTL(vertices, triangles) {
  const triCount = triangles.length / 3;
  const buffer = new ArrayBuffer(84 + triCount * 50);
  const view = new DataView(buffer);

  view.setUint32(80, triCount, true);

  let offset = 84;
  for (let i = 0; i < triCount; i++) {
    const [a, b, c] = [
      triangles[i * 3],
      triangles[i * 3 + 1],
      triangles[i * 3 + 2],
    ];

    const n = computeNormal(vertices, a, b, c);
    view.setFloat32(offset, n.x, true); offset += 4;
    view.setFloat32(offset, n.y, true); offset += 4;
    view.setFloat32(offset, n.z, true); offset += 4;

    for (const idx of [a, b, c]) {
      view.setFloat32(offset, vertices[idx * 3], true);     offset += 4;
      view.setFloat32(offset, vertices[idx * 3 + 1], true); offset += 4;
      view.setFloat32(offset, vertices[idx * 3 + 2], true); offset += 4;
    }

    view.setUint16(offset, 0, true); offset += 2;
  }

  return new Blob([buffer], { type: 'model/stl' });
}

Little-endian everywhere (the true argument to DataView methods). Every major slicer reads binary STL fine. There's no reason to ship ASCII in 2026.

What I'd Do Differently

Three things I'd change if I were rebuilding this:

1. Use WebAssembly for decimation from day one. I wrote the QEM decimator in pure JS first, and it worked, but a WASM port of MeshOptimizer would be roughly 3x faster with half the memory footprint. If your mesh library has a C++ reference implementation, wrap it, don't rewrite it.

2. Offload to WebGPU where available. For rasterizing SVG paths into a mask, and for computing vertex adjacency during decimation, WebGPU compute shaders would destroy my CPU implementation. The fallback path still needs to exist for Safari and older browsers, but on Chrome/Edge it's a free 10x speedup.

3. Design the STL writer to stream. Right now I build the whole mesh in memory, then serialize. For very large meshes (5M+ triangles, which you'd never 3D-print but some users try), I should stream triangle batches directly into the output Blob.

Try It, Break It, Tell Me What Went Wrong

If you've got a weird image, a stubborn SVG, or a QR code with a logo overlay — throw it at these tools and see what happens:

If you find a mesh it chokes on, reply here or drop a comment and I'll dig into it.

Happy printing.

Written by the Omnvert team. We build privacy-first browser tools for images, PDFs, audio, 3D models, and network diagnostics.