DEV Community: toolzip

Why Chrome Saves Images as .webp — And How to Convert Them Without Uploading

toolzip — Sat, 12 Sep 2026 13:48:07 +0000

You right-clicked an image in Chrome, hit "Save image as", and ended up with a .webp file. Now it won't open in Windows Photos, won't send via WhatsApp, and won't upload to half the platforms you need it for.

Here's what's happening and how to fix it — without uploading your files to a third-party server.

Why Chrome Saves Images as WebP

WebP is an image format developed by Google in 2010. At equivalent visual quality, WebP files are roughly 25–35% smaller than JPEG and up to 50% smaller than PNG. For websites serving millions of images, that's significant bandwidth savings.

So Google, YouTube, most e-commerce sites, and a large portion of the web now serve images in WebP format. When you save an image from Chrome, you get whatever format the server originally sent — which is increasingly WebP.

The format itself is technically superior to JPEG in most metrics:

Format	Typical size (vs JPEG)	Transparency	Lossless	Animation
JPEG	100% (baseline)	❌	❌	❌
PNG	150–300%	✅	✅	❌
WebP	65–75%	✅	✅	✅

The problem is compatibility outside the browser.

Where WebP Breaks Down

Browser support for WebP is essentially universal as of 2026. Chrome, Firefox, Edge, and Safari 16+ all handle it natively.

The issue is everywhere else:

Windows: The built-in Photos app doesn't support WebP without a codec extension from the Microsoft Store. Most Windows users won't have it installed.

Messaging apps: WhatsApp, Telegram, KakaoTalk — most messaging platforms don't accept WebP for image sending. You can send it as a file, but not as a photo.

Social platforms: Instagram and many others reject WebP uploads or silently convert them in ways that can affect quality.

Image editors: Older versions of Photoshop, GIMP, and most non-web-focused editors don't support WebP natively.

Email: WebP in email bodies is largely unsupported. Inline images in WebP format often appear broken.

Print services: Virtually no print shop accepts WebP.

Converting Without a Server

Most online converters solve this by uploading your file to their infrastructure, converting it server-side, and letting you download the result. That's a reasonable trade-off for generic images — but not for screenshots of private documents, personal photos, or anything confidential.

Browser-based conversion using the Canvas API is a cleaner approach:

function webpToJpg(file, quality = 0.92) {
  return new Promise((resolve) => {
    const img = new Image();
    const url = URL.createObjectURL(file);

    img.onload = () => {
      const canvas = document.createElement("canvas");
      canvas.width = img.naturalWidth;
      canvas.height = img.naturalHeight;

      const ctx = canvas.getContext("2d");
      // Fill white background (JPEG doesn't support transparency)
      ctx.fillStyle = "#ffffff";
      ctx.fillRect(0, 0, canvas.width, canvas.height);
      ctx.drawImage(img, 0, 0);

      canvas.toBlob((blob) => {
        URL.revokeObjectURL(url);
        resolve(blob);
      }, "image/jpeg", quality);
    };

    img.src = url;
  });
}

The key detail: JPEG doesn't support transparency. If the original WebP has a transparent background, you need to fill it before converting — otherwise the transparent areas become black. The white fill above handles this.

For PNG output (which preserves transparency):

canvas.toBlob((blob) => {
  resolve(blob);
}, "image/png");
// No quality parameter needed — PNG is lossless

Handling Multiple Files

For batch conversion, process files sequentially to avoid memory issues with large images:

async function convertBatch(files, format = "image/jpeg", quality = 0.92) {
  const results = [];

  for (const file of files) {
    const blob = await convertFile(file, format, quality);
    results.push({
      name: file.name.replace(/\.webp$/i, format === "image/jpeg" ? ".jpg" : ".png"),
      blob,
      originalSize: file.size,
      convertedSize: blob.size,
    });
  }

  return results;
}

When to Use JPG vs PNG Output

Use JPG when:

The image is a photograph
File size matters
The original has no transparency
You're sharing via messaging or email

Use PNG when:

The original WebP has a transparent background
You need lossless quality
You're using the image in a design context

A quick way to check for transparency: if the image has a checkered pattern in the background when viewed in a browser, it has transparency and should be converted to PNG.

Try It

ToolZip's WebP converter handles this entirely in your browser — no upload, no server, no account required. Supports batch conversion and outputs both JPG and PNG.

toolzip.app/tools/webp-to-jpg

ToolZip — 48 free browser-based tools. Everything runs client-side.
toolzip.app

Resize Images in Your Browser — No Upload, No Server, Free

toolzip — Sat, 12 Sep 2026 01:41:05 +0000

Most image resizing tools fall into two categories: desktop software that requires installation, or online services that upload your files to a server. Neither is ideal when you need a quick resize and want to keep your files private.

ToolZip's image resizer handles everything in your browser using the Canvas API. Your file never leaves your device.

Resize vs Compress — What's the Difference?

These two operations are often confused, but they work differently:

Operation	What it does	Result
Resize	Reduces pixel dimensions	Fewer pixels → smaller file
Compress	Reduces quality encoding	Same pixels → smaller file

Resizing a 4000×3000 photo to 1200×900 reduces the pixel count by 9x — and file size drops proportionally. Compression keeps the same resolution but sacrifices some quality to reduce file size.

For maximum reduction, do both: resize first to reduce dimensions, then compress to reduce quality. A 5MB smartphone photo can become 200–300KB this way with no visible quality loss at typical display sizes.

Why Resizing Matters

Modern smartphone cameras shoot at 4000px, 8000px, even higher. For web use, that resolution is rarely necessary.

A blog post body column is typically 800–1200px wide. Uploading a 4000px image and letting the browser scale it down wastes bandwidth, slows page loads, and uses unnecessary storage on your hosting.

Google's Core Web Vitals include LCP (Largest Contentful Paint) — which is often an image. Oversized images directly hurt your SEO score.

Recommended Dimensions by Use Case

Use case	Recommended width
Blog post body	1200px max
Blog thumbnail	800px
Instagram post	1080px
Instagram Stories / Reels	1080×1920px
Email attachment	800px max
WhatsApp / messaging	1000px max
Icon / logo	200px or less

How ToolZip's Resizer Works

ToolZip uses the browser's native Canvas API:

const canvas = document.createElement("canvas");
canvas.width = targetWidth;
canvas.height = targetHeight;
const ctx = canvas.getContext("2d");
ctx.drawImage(img, 0, 0, targetWidth, targetHeight);
canvas.toBlob((blob) => {
  // Download the resized image
}, "image/jpeg", quality);

No WebAssembly, no FFmpeg — just the Canvas API that every modern browser ships with. That means:

Instant processing (no loading time)
No file size limits
Works offline after initial page load
Zero server involvement

Features

Pixel input: Set exact width and height
Percentage input: Scale to 50%, 75%, etc.
Aspect ratio lock: Enter width only, height calculates automatically
Batch processing: Multiple files at once
Format output: JPG, PNG, WebP

The Resize + Compress Workflow

For blog images:

Original: 4032×3024px, 5.2MB (typical smartphone photo)
  ↓ Resize to 1200×900px
  ↓ Compress at 80% quality
Result: ~180KB — 97% size reduction

The image displays at the same visual size in the blog post. No perceptible quality difference at typical viewing distances.

Try It

toolzip.app/tools/image-resize

No signup. No upload. Works on Chrome, Edge, Firefox, and Safari.

ToolZip — 48 free browser-based tools for image, video, PDF, text, and developer use. Everything runs client-side.
toolzip.app

AVIF vs WebP vs JPEG — Which Image Format Should You Use in 2026?

toolzip — Fri, 11 Sep 2026 12:31:05 +0000

If you've ever saved an image from Chrome and ended up with a .avif file that nothing could open, you've encountered the format wars firsthand. AVIF is the newest player in image compression — and it's genuinely impressive. But "impressive" doesn't always mean "use it everywhere."

Here's a practical breakdown of when to use AVIF, when to stick with WebP or JPEG, and how to convert between them without uploading your files to a server.

What Is AVIF?

AVIF (AV1 Image File Format) is an image format derived from the AV1 video codec, developed by the Alliance for Open Media — a consortium that includes Google, Apple, Netflix, and Mozilla.

It's genuinely next-generation:

~50% smaller than JPEG at equivalent visual quality
~20% smaller than WebP at equivalent visual quality
Supports HDR, wide color gamut, transparency, and animation
Completely royalty-free

Netflix uses AVIF for thumbnail images. Google Fonts serves AVIF where supported. The Squoosh team at Google has benchmarked it extensively — the compression gains are real.

Browser Support in 2026

Browser	AVIF Support
Chrome 94+	✅ Full
Firefox 93+	✅ Full
Safari 16+	✅ Full
Edge 94+	✅ Full
IE	❌ Never

Browser support is essentially universal for modern browsers. The problem is everything outside the browser.

Where AVIF Breaks Down

Native OS image viewers:
Windows Photos and macOS Preview don't support AVIF natively. Save an AVIF from Chrome on Windows and you get an icon with no preview.

Messaging apps:
WhatsApp, KakaoTalk, Telegram — most messaging apps don't handle AVIF. Send an AVIF file and the recipient either can't open it or sees a broken image.

Older image editors:
Photoshop added AVIF support relatively recently. Older versions and many non-Adobe editors don't support it.

Email clients:
Gmail, Outlook — AVIF in email is largely unsupported.

Format Comparison

Format	File Size	Quality	Transparency	Animation	Compatibility
JPEG	Baseline	Good	❌	❌	Universal
PNG	Large	Lossless	✅	❌	Universal
WebP	~30% < JPEG	Good	✅	✅	Modern browsers
AVIF	~50% < JPEG	Excellent	✅	✅	Modern browsers only

When to Use Each Format

Use JPEG when:

Maximum compatibility is required (email, messaging, older apps)
File size matters but you can't guarantee browser support
You're working with photographs destined for print

Use PNG when:

You need transparency
You're working with logos, icons, or screenshots with text
Lossless quality is non-negotiable

Use WebP when:

You're serving images on the web and want a safe modern format
You need transparency without PNG's file size
You want broad support without worrying about edge cases

Use AVIF when:

You're optimizing web performance and control the serving environment
Your analytics confirm your users are on modern browsers
You can serve fallbacks via <picture> tag

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="Fallback">
</picture>

Converting AVIF Without Uploading Files

Most online converters require you to upload your file to their servers. For images containing sensitive content — screenshots, documents, personal photos — that's not ideal.

ToolZip's AVIF converter handles conversion entirely in your browser using the Canvas API and the browser's native AVIF decoder. Your file never leaves your device.

Supported conversions:

AVIF → JPG
AVIF → PNG
AVIF → WebP
JPG/PNG/WebP → AVIF (Chrome 94+ required for encoding)

The encoding direction (to AVIF) requires Chrome 94+ because it uses the browser's built-in AV1 encoder via HTMLCanvasElement.toBlob() with image/avif mime type. Firefox and Safari support decoding but not yet encoding via Canvas.

The Practical Verdict

AVIF is the future. But "the future" means you need a fallback strategy today.

For web performance: serve AVIF with WebP and JPEG fallbacks.
For sharing and compatibility: convert to JPEG before sending.
For archiving: keep originals as PNG or AVIF, convert on demand.

Convert AVIF files without uploading at toolzip.app/tools/avif-converter

ToolZip — 48 free browser-based tools. Everything runs client-side.

Convert Videos in Your Browser — No Upload, No Server, Free (MP4, MOV, WebM, AVI, MKV)

toolzip — Thu, 10 Sep 2026 04:21:27 +0000

Most video conversion tools work the same way: you upload your file, wait for the server to process it, then download the result. That means your file — a personal recording, a work presentation, anything confidential — travels to a stranger's server.

ToolZip's video format converter runs entirely in your browser using FFmpeg.wasm. Your file never leaves your device.

Why Video Formats Matter

A video file has two layers: a container (MP4, MKV, AVI) and a codec (H.264, H.265, VP9). The container is the wrapper; the codec is how the video is compressed inside. Same MP4, different codec — and it might not play.

Here's a quick breakdown of the most common formats:

MP4

The universal standard. Plays everywhere — phones, TVs, browsers, messaging apps. Best choice for sharing, uploading to YouTube, sending via WhatsApp or email.

MOV

Apple's native format. iPhone and Mac record in MOV by default. High quality, great for editing — but Windows doesn't play it natively without extra codecs.

WebM

Google's open-source format for the web. Smaller file size than MP4 at the same quality. Perfect for embedding video on websites, but poor support in native apps and messaging.

AVI

Microsoft's legacy format from 1992. Still works on Windows, but massive file sizes and no streaming support make it increasingly irrelevant. No smartphone support.

MKV

The feature-rich container. Supports multiple audio tracks, multiple subtitle tracks, chapters, and almost every codec. Widely used for HD movies — but won't upload to YouTube or send via messaging apps.

When to Convert

Situation	Target format
Upload to YouTube / Instagram	MP4
Send via WhatsApp / KakaoTalk	MP4
iPhone MOV → play on Windows	MP4
MKV movie → smartphone	MP4
Embed video on a website	WebM or MP4
Video editing source file	MOV or MKV

How the Browser Conversion Works

ToolZip uses FFmpeg compiled to WebAssembly. The entire processing pipeline runs inside your browser tab — no data is transmitted to any server.

Select file
→ FFmpeg.wasm loads (~30MB, cached after first use)
→ Conversion runs locally
→ Download converted file
→ No network request for the file

Verify it yourself: open DevTools → Network tab → convert a video. You'll see the FFmpeg core load once, then nothing. The file stays on your machine.

Implementation

FFmpeg loads from unpkg CDN on first use:

const baseURL = "https://unpkg.com/@ffmpeg/core@0.12.6/dist/umd";
await ffmpeg.load({
  coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
});

The conversion command remuxes the container while re-encoding with libx264:

await ffmpeg.exec([
  "-i", `input.${inputExt}`,
  "-vcodec", "libx264",
  "-acodec", "aac",
  `output.${targetExt}`
]);

For WebM output, VP9 is used instead:

await ffmpeg.exec([
  "-i", `input.${inputExt}`,
  "-vcodec", "libvpx-vp9",
  "-acodec", "libopus",
  "output.webm"
]);

After processing, the result is read back as a Blob and served as a download — no round trip anywhere.

First Load

FFmpeg.wasm is ~30MB. On first use, it loads in 5–15 seconds depending on connection speed. After that, it's cached in the browser and starts instantly on future visits.

This is the cost of running entirely client-side. For privacy-sensitive files, it's worth it.

Supported Conversions

Any combination of: MP4 ↔ MOV ↔ WebM ↔ AVI ↔ MKV

Tool	Description
Video Compress	Re-encode with CRF control (High/Medium/Low)
Video Trim	Dual-handle range slider with preview before cutting
Video to GIF	Clip to GIF with FPS + width control, side-by-side preview
Thumbnail Extract	Seek to any frame, save as JPG via Canvas API
Audio Extract	Pull MP3 from any video with built-in player

Try It

toolzip.app/tools/video-convert

No signup. No watermark. No upload. Works on Chrome, Edge, Firefox, and Safari (desktop recommended for large files).

ToolZip — 48 free browser-based tools. Everything runs client-side.
toolzip.app

Compress Videos in Your Browser — No Upload, No Server, Free

toolzip — Mon, 07 Sep 2026 12:48:54 +0000

Most free video compression tools require you to upload your file to their servers. That means your personal videos, work recordings, or confidential footage gets sent to a third-party server you don't control.

ToolZip's video compressor runs entirely in your browser using FFmpeg.wasm — your file never leaves your device.

How It Works

FFmpeg is the industry-standard video processing tool used by YouTube, VLC, and countless other platforms. ToolZip compiles it to WebAssembly (WASM) so it runs directly in the browser with no server involved.

User selects file
→ FFmpeg.wasm loads (~30MB, cached after first use)
→ Compression runs locally in browser
→ Download compressed file
→ No network request for the file itself

You can verify this yourself: open DevTools → Network tab → no file upload request occurs.

Features

Three quality presets: High (near-original), Medium (balanced, recommended), Low (smallest size)
Formats supported: MP4, MOV, WebM, AVI, MKV
Output: MP4 (H.264 + AAC via libx264)
No file size limit (larger files = longer processing time)
No signup, no watermark, completely free

The Trade-off: First Load Time

FFmpeg.wasm is ~30MB. On first use, it takes 5–15 seconds to load depending on your connection. After that, it's cached in the browser and loads instantly.

This is the cost of running entirely client-side — worth it for privacy-sensitive files.

Typical Compression Results

Original	Compressed (Medium)	Reduction
100MB	~30–50MB	50–70%
500MB	~150–250MB	50–70%

Results vary based on the original encoding, bitrate, and resolution.

Tech Stack

FFmpeg.wasm (@ffmpeg/ffmpeg + @ffmpeg/util)
Next.js 16 (App Router)
Deployed on Vercel

FFmpeg is loaded from unpkg CDN on first use:

const baseURL = "https://unpkg.com/@ffmpeg/core@0.12.6/dist/umd";
await ffmpeg.load({
  coreURL: await toBlobURL(`${baseURL}/ffmpeg-core.js`, "text/javascript"),
  wasmURL: await toBlobURL(`${baseURL}/ffmpeg-core.wasm`, "application/wasm"),
});

The compression command uses libx264 with CRF control:

// Medium quality: CRF 28
await ffmpeg.exec([
  "-i", inputFile,
  "-vcodec", "libx264",
  "-crf", "28",       // 18=high, 28=medium, 35=low
  "-preset", "fast",
  "-acodec", "aac",
  "output.mp4"
]);

Try It

toolzip.app/tools/video-compress

No signup required. Works on Chrome, Edge, Firefox, and Safari (desktop recommended for large files).

ToolZip is a collection of 48 free browser-based tools for image, video, PDF, text, and developer utilities. All processing happens client-side — no file uploads, no server.

How I Built a Client-Side PDF Toolkit — 6 Tools, No Server

toolzip — Fri, 04 Sep 2026 08:25:58 +0000

When I started building ToolZip, I made one rule: no file uploads. Everything had to run in the browser.

Images were straightforward — the Canvas API handles compression, conversion, and cropping natively. But PDF manipulation was a different challenge entirely. PDFs are binary, complex, and traditionally require server-side processing.

Here's how I built 6 PDF tools that run entirely client-side, and what I learned along the way.

The Tools

The PDF category now includes:

PDF Merge — Combine multiple PDFs, reorder before merging
PDF Split — Extract pages by range or split into individual files PDF Compress — Reduce file size using object streams
Image to PDF — Convert JPG/PNG images into a single PDF
PDF Rotate — Rotate individual pages or all at once
PDF to Image — Export each page as PNG or JPG

All of them run in the browser. No file ever leaves the user's device.

The Core Library: pdf-lib

pdf-lib is the foundation for 5 of the 6 tools. It's a pure JavaScript library that can create and modify PDFs entirely in the browser using ArrayBuffers.

import { PDFDocument, degrees } from 'pdf-lib';

// Load a PDF from a File input
const arrayBuffer = await file.arrayBuffer();
const pdf = await PDFDocument.load(arrayBuffer);

// Copy pages to a new document
const newPdf = await PDFDocument.create();
const [page] = await newPdf.copyPages(pdf, [0]); // page index 0
newPdf.addPage(page);

// Save and download
const bytes = await newPdf.save();
const blob = new Blob([bytes], { type: 'application/pdf' });

The API is clean and the library handles the complexity of PDF structure internally. For merge, split, rotate, compress, and image-to-PDF — pdf-lib covers everything.

PDF Merge

The merge tool lets users add multiple files, reorder them with up/down buttons, then combine into one PDF.

const merged = await PDFDocument.create();

for (const file of orderedFiles) {
  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));
}

const output = await merged.save();

The key insight: copyPages handles all the internal reference copying. You don't need to worry about fonts, images, or annotations embedded in each page — they come along automatically.

PDF Split

Split supports two modes: extract a page range, or split every page into a separate file.

// Parse ranges like "1-3, 5, 7-9" into zero-indexed page numbers
const parseRange = (rangeStr, total) => {
  const pages = [];
  rangeStr.split(',').forEach(part => {
    const [start, end] = part.trim().split('-').map(n => parseInt(n) - 1);
    if (end !== undefined) {
      for (let i = start; i <= end; i++) pages.push(i);
    } else {
      pages.push(start);
    }
  });
  return pages.filter(p => p >= 0 && p < total);
};

For "split all pages" mode, I create a separate PDF for each page and trigger sequential downloads with a small delay between them to avoid browser throttling:

for (let i = 0; i < pageCount; i++) {
  const singlePage = await PDFDocument.create();
  const [page] = await singlePage.copyPages(srcPdf, [i]);
  singlePage.addPage(page);
  const output = await singlePage.save();
  downloadBlob(output, `page_${i + 1}.pdf`);
  await new Promise(r => setTimeout(r, 200)); // prevent throttling
}

PDF Compress

PDF compression is the trickiest of the six tools to explain honestly. pdf-lib's save() method accepts a useObjectStreams option that compresses the PDF's internal object references:

const output = await pdf.save({ useObjectStreams: true });

This works well for PDFs with many internal objects (text-heavy documents, lots of annotations). But PDFs that are already compressed, or that are mostly scanned images, won't shrink much this way.

For significant image compression inside PDFs, you'd need to re-render each page and re-embed the images at lower quality — which is possible but much more complex. I've kept the current implementation simple and transparent: it shows users the before and after size so they can see exactly what changed.

Image to PDF

This one is straightforward: load images, draw them onto PDF pages at the image's natural dimensions.

const pdf = await PDFDocument.create();

for (const file of imageFiles) {
  let img;
  if (file.type === 'image/jpeg') {
    img = await pdf.embedJpg(await file.arrayBuffer());
  } else {
    // Convert PNG/other to JPEG via canvas
    const bitmap = await createImageBitmap(file);
    const canvas = document.createElement('canvas');
    canvas.width = bitmap.width;
    canvas.height = bitmap.height;
    canvas.getContext('2d').drawImage(bitmap, 0, 0);
    const blob = await new Promise(r => canvas.toBlob(r, 'image/jpeg', 0.92));
    img = await pdf.embedJpg(await blob.arrayBuffer());
  }

  const page = pdf.addPage([img.width, img.height]);
  page.drawImage(img, { x: 0, y: 0, width: img.width, height: img.height });
}

One thing to note: pdf-lib's embedPng exists but I found converting everything to JPEG via canvas was more reliable across different PNG types (transparent backgrounds, indexed color, etc.).

PDF to Image: The Odd One Out

PDF to Image is the one tool that doesn't use pdf-lib — because pdf-lib can read and write PDFs, but it can't render them visually.

For rendering, I load PDF.js from CDN at runtime:

// Load PDF.js only when needed
if (!window.pdfjsLib) {
  await new Promise((resolve, reject) => {
    const script = document.createElement('script');
    script.src = 'https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.min.js';
    script.onload = resolve;
    script.onerror = reject;
    document.head.appendChild(script);
  });
  window.pdfjsLib.GlobalWorkerOptions.workerSrc =
    'https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.worker.min.js';
}

// Render each page to canvas
const pdfDoc = await pdfjsLib.getDocument({ data: arrayBuffer }).promise;

for (let i = 1; i <= pdfDoc.numPages; i++) {
  const page = await pdfDoc.getPage(i);
  const viewport = page.getViewport({ scale: 2 }); // 2x for quality
  const canvas = document.createElement('canvas');
  canvas.width = viewport.width;
  canvas.height = viewport.height;
  await page.render({
    canvasContext: canvas.getContext('2d'),
    viewport
  }).promise;

  const dataUrl = canvas.toDataURL('image/png');
  // offer for download
}

The scale factor matters. Scale 1 gives you screen resolution (~96dpi), scale 2 gives you print-quality (~192dpi). I let users choose between 1x, 2x, and 3x.

What I'd Do Differently

Lazy load pdf-lib. It's about 800KB uncompressed. I now use dynamic import() to load it only when the user actually opens a PDF tool, rather than on initial page load.

Show compression stats upfront. For PDF Compress, showing the expected size reduction before processing would set better expectations.

Web Workers for large files. Processing large PDFs on the main thread can freeze the UI momentarily. Moving the heavy operations to a Web Worker would make the experience smoother.

Try It

All 6 tools are live at toolzip.app under the PDF category. No signup, no upload, no server.

If you've built client-side PDF tools before, I'd be curious what libraries or approaches you used — drop a comment below.

Building a Barcode Generator That Actually Works — The bwip-js EAN-13 Deep Dive

toolzip — Wed, 02 Sep 2026 12:34:28 +0000

If you've ever tried to render an EAN-13 barcode with an add-on code in the browser, you know it's more complicated than it looks. This is the story of how I solved it for ToolZip.

The Problem

EAN-13 is the standard barcode on most retail products worldwide. It's 13 digits, with distinctive "guard bars" — the longer bars at the left edge, center, and right edge that scanners use to orient themselves.

Many ISBN books also use an EAN-5 add-on: a separate 5-digit barcode attached to the right side of the main barcode, typically encoding the price.

I was using bwip-js, the most complete barcode library available for JavaScript. It works great — until you need both EAN-13 and EAN-5 together with text labels.

The bwip-js includetext Bug

bwip-js has an option called includetext that renders the human-readable digits below the bars. This is what you see on every product barcode — the numbers printed under the bars.

Here's the problem: when includetext: true is set with an EAN-5 add-on, the digit glyphs overlap with the bars.

My first instinct: set includetext: false and add the text manually.

// ❌ This breaks the guard bars
bwipjs.toSVG({
  bcid: 'ean13',
  text: '9791190333146 07810',
  includetext: false, // Guard bars disappear!
});

This removed the guard bars entirely. The guard bars are part of the includetext rendering path in bwip-js — they don't render without it.

Why Guard Bars Matter

Guard bars aren't decorative. They're functionally required:

Left guard:   Tells the scanner where the barcode starts
Center guard: Divides the left and right digit groups
Right guard:  Tells the scanner where it ends

A barcode without guard bars won't scan. Setting includetext: false was not an option.

The Solution: Keep includetext, Remove the Glyphs

The key insight: includetext: true renders both the guard bars and the digit glyphs as SVG path elements. I can keep the guard bars by keeping includetext: true, then surgically remove just the digit glyph paths and replace them with <text> SVG elements positioned correctly.

Step 1: Generate with includetext: true

// Server-side (Next.js API route)
const rawSvg = bwipjs.toSVG({
  bcid: 'ean13',
  text: '9791190333146 07810',
  scale: 2,
  height: 10,
  includetext: true,  // ← Must stay true
  textxalign: 'center',
  guardwhitespace: true,
});

Step 2: Identify the SVG structure

The generated SVG contains:

<path stroke=...> elements — the bars (keep these)
<path fill="#000000"> elements — the digit glyphs (remove these)
The LMI > symbol — a small chevron bwip-js adds after EAN-5 (remove this)

const fills = [...rawSvg.matchAll(
  /<path d="([^"]+)" fill="#000000" \/>/g
)];
// fills[0] = all digit glyphs (EAN-13 + EAN-5)
// fills[1] = LMI chevron symbol

Step 3: Calculate text positions from bar positions

The bars themselves tell us where to position the text. I parse the stroke path M/L coordinates to find:

const segs = [...rawSvg.matchAll(/M(\d+) (\d+)L(\d+) (\d+)/g)];
const allX = [...new Set(segs.map(m => +m[1]))].sort((a,b) => a-b);

// Find the gap between EAN-13 bars and EAN-5 bars
let splitIdx = 0;
for (let i = 1; i < allX.length; i++) {
  if (allX[i] - allX[i-1] > 20) { splitIdx = i; break; }
}

const ean13Xs = allX.slice(0, splitIdx);
const ean5Xs  = allX.slice(splitIdx);

Then find the center guard bar position:

let midGapIdx = 0, maxGap = 0;
for (let i = 1; i < ean13Xs.length; i++) {
  const gap = ean13Xs[i] - ean13Xs[i-1];
  if (gap > maxGap) { maxGap = gap; midGapIdx = i; }
}

const leftBarEndX    = ean13Xs[midGapIdx - 1];
const rightBarStartX = ean13Xs[midGapIdx];
const leftGuardX     = ean13Xs[0];
const rightGuardX    = ean13Xs[ean13Xs.length - 1];

Step 4: Place text elements

const LEFT_PAD = 26;

const texts = [
  // "9" — left of first guard bar
  `<text
    x="${LEFT_PAD + leftGuardX - 4}"
    y="${ean13TextY}"
    font-family="monospace"
    font-size="18"
    text-anchor="end">
    ${value[0]}
  </text>`,

  // "791190" — centered between left guard and center guard
  `<text
    x="${LEFT_PAD + (leftGuardX + leftBarEndX) / 2}"
    y="${ean13TextY}"
    font-family="monospace"
    font-size="18"
    text-anchor="middle">
    ${value.slice(1, 7)}
  </text>`,

  // "333146" — centered between center guard and right guard
  `<text
    x="${LEFT_PAD + (rightBarStartX + rightGuardX) / 2}"
    y="${ean13TextY}"
    font-family="monospace"
    font-size="18"
    text-anchor="middle">
    ${value.slice(7, 13)}
  </text>`,

  // EAN-5 — centered over EAN-5 bars, ABOVE the barcode
  `<text
    x="${LEFT_PAD + (ean5Xs[0] + ean5Xs[ean5Xs.length-1]) / 2}"
    y="${ean5TextY}"
    font-family="monospace"
    font-size="16"
    text-anchor="middle">
    ${addon}
  </text>`,
].join('\n');

The Leading Zero Problem

One more gotcha: EAN-5 add-on codes are always 5 digits. A price of 7,810 Korean Won encodes as 07810.

If you render this as a JavaScript number, 07810 becomes 7810. The leading zero disappears.

Always pass the add-on as a string:

// ❌ Wrong
const addon = 07810; // → 7810

// ✅ Correct
const addon = "07810"; // → "07810"

// In SVG text element:
`${addon}` // renders as "07810" correctly

Why Server-Side?

I generate barcodes in a Next.js API route, not in the browser.

The reason: bwip-js renders differently in Node.js vs browser environments. The browser version uses a canvas-based renderer that produces slightly different SVG output, making the glyph extraction logic unreliable.

Running it server-side gives consistent, predictable output every time:

// app/api/barcode/route.ts
export async function GET(req: NextRequest) {
  const bwipjs = (await import("bwip-js")).default;
  const rawSvg = bwipjs.toSVG({ ... });
  // post-process SVG
  return new NextResponse(processedSvg, {
    headers: { "Content-Type": "image/svg+xml" },
  });
}

The Result

The final barcode renders correctly:

        07810          ← EAN-5 above, centered
    ▌▌▌▌▌▌▌▌▌▌▌▌▌▌    ← EAN-13 bars with guard bars
9  791190   333146     ← 1 + 6 + 6 digit layout

Scannable, standard-compliant, and rendered entirely as SVG — no raster images, infinitely scalable for print.

Try It

The barcode generator is live at toolzip.app/tools/qr-barcode. It supports ISBN, EAN-13, EAN-8, UPC-A, Code 128, Code 39, and ISSN.

If you've run into similar bwip-js quirks or have questions about the SVG post-processing approach, drop a comment — happy to discuss.

I built a free browser-based image & utility toolkit — here's what I learned

toolzip — Mon, 31 Aug 2026 13:12:04 +0000

Why I Built ToolZip

A few months ago, I needed to compress some images for a client project. I searched for a free online tool, found one, uploaded my files — and then realized I had no idea what they were doing with those files on their servers.

That bothered me. So I built ToolZip — a collection of browser-based tools where everything runs locally. No files ever leave your device.

What It Does

ToolZip currently has 18 tools across several categories:

Image tools

Compress JPG & PNG (using browser-image-compression)
Convert HEIC → JPG (iPhone photos, using heic2any)
Convert WEBP → JPG/PNG
Resize, crop, rotate

Developer tools

JSON formatter with error highlighting and line numbers
URL encoder/decoder with query string parser
Base64 encoder/decoder (supports images too)
Unix timestamp converter (live current time display)
Color converter (HEX ↔ RGB ↔ HSL with palette generator)

Utilities

QR code & barcode generator
Password generator (Web Crypto API)
Special characters & emoji copy tool
3D file viewer (OBJ, GLB, FBX, STL, BVH, PLY)

Tech stack: Next.js 14 (App Router), deployed on Vercel, all processing via Canvas API and Web Workers.

The Hardest Part: EAN-13 Barcodes

I want to share one specific challenge that took way longer than expected: rendering EAN-13 barcodes with the EAN-5 add-on correctly.

The library I used (bwip-js) has a known bug where enabling includetext: true causes the text digits to overlap with the bars when an add-on code is present.

My first instinct was to set includetext: false and manually position the text. But this removed the guard bars (the longer bars at the edges and center of an EAN-13 barcode) — which are actually encoded as part of the includetext rendering logic.

The solution: Keep includetext: true (to preserve guard bars), extract and remove the glyph paths from the SVG, then re-render the digits as <text> SVG elements at the correct positions.

// Server-side (Next.js API route)
const rawSvg = bwipjs.toSVG({
  bcid: 'ean13',
  text: '9791190333146 07810',
  scale: 2,
  height: 10,
  includetext: true,  // ← must stay true (guard bars)
  guardwhitespace: true,
});

// Remove digit glyphs, re-add as <text> elements
// with correct x positions calculated from bar positions

For the EAN-5 add-on digits, I had to render them as strings, not numbers — because 07810 rendered as a number becomes 7810 (leading zero disappears).

Small detail, big headache. 😅

The 3D Viewer Challenge

Another interesting part was building the 3D file viewer.

I initially loaded Three.js via CDN and referenced it as window.THREE. This caused intermittent failures because the script hadn't finished loading when the component initialized.

Fix: Switch to npm import.

import * as THREE from "three";

Simple, but it took me an embarrassingly long time to diagnose.

For BVH (motion capture) files, the challenge was different. BVH bone coordinates are in centimeter scale (hundreds of units), so I had to:

Add root bones to a group
Calculate bounding box from bone positions directly
Apply scale
Then call group.updateWorldMatrix(true, true)
Then create SkeletonHelper(group)

Order matters — creating the helper before updating the matrix results in incorrect bone positions.

What I'd Do Differently

1. Lazy load tool components from the start

All 18 tools currently live in one large JSX file (~5,000 lines). It works, but as the tool count grows this will affect initial load time. I'm planning to split them into separate files with dynamic imports.

2. Server-side generation for complex outputs

The barcode generator taught me that some things are better handled server-side. Browser rendering of the same library can differ from Node.js rendering in subtle ways. I moved barcode generation to a Next.js API route, which resolved all inconsistencies.

3. Test with real files earlier

I discovered most BVH and FBX edge cases only after users started uploading their actual files. A broader test dataset would have saved time.

Traffic & SEO Notes

ToolZip launched about a week ago. Here's what I've noticed so far:

Google Search Console shows the sitemap was accepted (13+ pages indexed)
No organic traffic yet — expected for a new domain
The "no server upload" angle resonates well in communities like Reddit

I'm writing Korean blog posts targeting local SEO as well, since that's my primary market for now.

What's Next

Hash generator (MD5, SHA-256 via Web Crypto API)
Regex tester
Markdown preview
More 3D formats (MMD/PMX for the anime community)

If you try ToolZip and something doesn't work as expected, I'd genuinely appreciate feedback — either here in the comments or at hello@toolzip.app.

Live site: toolzip.app

DEV Community: toolzip

Why Chrome Saves Images as .webp — And How to Convert Them Without Uploading

Why Chrome Saves Images as WebP

Where WebP Breaks Down

Converting Without a Server

Handling Multiple Files

When to Use JPG vs PNG Output

Try It

Resize Images in Your Browser — No Upload, No Server, Free

Resize vs Compress — What's the Difference?

Why Resizing Matters

Recommended Dimensions by Use Case

How ToolZip's Resizer Works

Features

The Resize + Compress Workflow

Try It

AVIF vs WebP vs JPEG — Which Image Format Should You Use in 2026?

What Is AVIF?

Browser Support in 2026

Where AVIF Breaks Down

Format Comparison

When to Use Each Format

Converting AVIF Without Uploading Files

The Practical Verdict

Convert Videos in Your Browser — No Upload, No Server, Free (MP4, MOV, WebM, AVI, MKV)

Why Video Formats Matter

MP4

MOV

WebM

AVI

MKV

When to Convert

How the Browser Conversion Works

Implementation

First Load

Supported Conversions

Other Video Tools in ToolZip

Try It

Compress Videos in Your Browser — No Upload, No Server, Free

How It Works

Features

The Trade-off: First Load Time

Typical Compression Results

Other Video Tools in ToolZip

Tech Stack

Try It

How I Built a Client-Side PDF Toolkit — 6 Tools, No Server

The Tools

The Core Library: pdf-lib

PDF Merge

PDF Split

PDF Compress

Image to PDF

PDF to Image: The Odd One Out

What I'd Do Differently

Try It

Building a Barcode Generator That Actually Works — The bwip-js EAN-13 Deep Dive

The Problem

The bwip-js includetext Bug

Why Guard Bars Matter

The Solution: Keep includetext, Remove the Glyphs

Step 1: Generate with includetext: true

Step 2: Identify the SVG structure

Step 3: Calculate text positions from bar positions

Step 4: Place text elements

The Leading Zero Problem

Why Server-Side?

The Result

Try It

I built a free browser-based image & utility toolkit — here's what I learned

Why I Built ToolZip

What It Does

The Hardest Part: EAN-13 Barcodes

The 3D Viewer Challenge

What I'd Do Differently

Traffic & SEO Notes

What's Next