DEV Community: BeGoodTool.com

Why a precise image color picker needs two canvases (one to read pixels, one to draw the loupe)

Joe Lin — Thu, 27 Aug 2026 13:00:03 +0000

A while back I thought an image color picker would be a tiny weekend feature: upload an image, hover it, read a pixel, done.

What I didn't really appreciate until I built it is that the browser gives you display-space coordinates, while getImageData() wants real image pixels. And once you add a magnifier that has to feel trustworthy, you end up with a second canvas too.

The real job is mapping cursor space back to image space

The displayed <img> is responsive, but the actual color has to come from the image's natural pixel grid. So on load, the component draws the uploaded image onto a hidden canvas at naturalWidth × naturalHeight, then keeps a scale based on the rendered width:

const scale = computed(() =>
  naturalWidth.value && displayWidth.value
    ? displayWidth.value / naturalWidth.value
    : 1,
);

const getPixelAtClient = (clientX, clientY) => {
  const rect = stageWrapRef.value.getBoundingClientRect();
  let dx = clamp(clientX - rect.left, 0, rect.width - 1);
  let dy = clamp(clientY - rect.top, 0, rect.height - 1);
  const s = scale.value || 1;
  const natX = clamp(Math.floor(dx / s), 0, naturalWidth.value - 1);
  const natY = clamp(Math.floor(dy / s), 0, naturalHeight.value - 1);

  const ctx = mainCanvasEl.value.getContext("2d");
  const data = ctx.getImageData(natX, natY, 1, 1).data;
  return { r: data[0], g: data[1], b: data[2] };
};

That Math.floor(dx / s) part is the whole trick. Without it, you'd be sampling CSS pixels, not image pixels, and the picker would drift as soon as the image got resized.

There's another nice detail in the load path: the hidden canvas is created with willReadFrequently: true. That's exactly the right hint here, because this tool calls getImageData() over and over while the pointer moves.

The loupe isn't CSS zoom — it's a second canvas with smoothing disabled

The magnifier looked fuzzy until I stopped treating it like a visual effect and treated it like another rendering surface.

Instead of scaling the DOM image, the component copies a tiny source square around the target pixel onto a dedicated magnifier canvas:

const MAG_SIZE = 160;
const SRC_SIZE = 15;

const drawMagnifier = (natX, natY) => {
  const w = Math.min(SRC_SIZE, naturalWidth.value);
  const h = Math.min(SRC_SIZE, naturalHeight.value);
  const sx = clamp(natX - Math.floor(w / 2), 0, Math.max(0, naturalWidth.value - w));
  const sy = clamp(natY - Math.floor(h / 2), 0, Math.max(0, naturalHeight.value - h));

  const ctx = magnifierCanvasEl.value.getContext("2d");
  ctx.imageSmoothingEnabled = false;
  ctx.clearRect(0, 0, MAG_SIZE, MAG_SIZE);
  ctx.drawImage(mainCanvasEl.value, sx, sy, w, h, 0, 0, MAG_SIZE, MAG_SIZE);

imageSmoothingEnabled = false is what makes the loupe feel honest. You're seeing enlarged blocks, not blurred interpolation.

Then it draws guide lines and a red rectangle around the center pixel. I especially like that the crosshair leaves the center cell empty before continuing, so the indicator doesn't literally paint over the color you're trying to inspect.

Every picked pixel gets normalized into HEX, RGB, and HSL immediately

Once the picker has r, g, and b, it immediately builds all three output formats:

const toHex2 = (n) => n.toString(16).padStart(2, "0").toUpperCase();
const rgbToHex = (r, g, b) => `#${toHex2(r)}${toHex2(g)}${toHex2(b)}`;

const buildColorInfo = (r, g, b) => {
  const hsl = rgbToHslParts(r, g, b);
  return {
    r,
    g,
    b,
    hex: rgbToHex(r, g, b),
    rgb: `rgb(${r}, ${g}, ${b})`,
    hsl: `hsl(${hsl.h}, ${hsl.s}%, ${hsl.l}%)`,
  };
};

That sounds obvious, but it changes the UX a lot. The first click commits the color to the palette and copies HEX by default, while the side panel and saved swatches still let you copy RGB or HSL later. So the app stores one normalized color object instead of recomputing formats in three different places.

The HSL conversion is done manually too, with the usual max/min/delta branch logic. That's worth doing in the component because you want deterministic output formatting, not whatever a browser API happens to expose.

The gotchas are mostly about pixels not meaning what you think they mean

A few things here are messier than the happy-path demo suggests:

Compressed images lie a little. JPG artifacts and anti-aliased edges mean the pixel under the cursor may not match the flat brand color you thought you were sampling.
Alpha is currently ignored. getImageData() returns RGBA, but this component only keeps data[0], data[1], and data[2]. So with transparent PNGs, you're copying the stored RGB values, not an rgba(...) result that reflects transparency.
The screen picker is browser-dependent. The extra EyeDropper button only appears when window.EyeDropper exists, which effectively means Chromium-family browsers.
Canvas security rules still exist. This tool uses local uploads, which avoids most trouble, but the getImageData() call is still wrapped in try/catch for a reason. If you adapt the same pattern to cross-origin images, a tainted canvas will block pixel reads.

I cleaned this up into a small free tool while I was building it: Image Color Picker.

Available in other languages

圖片精確色碼擷取器 — 繁體中文
图片精确色码提取器 — 简体中文
Image Color Picker — English
画像カラーピッカー — 日本語
이미지 색상 추출기 — 한국어
Sélecteur de couleur d'image — Français
Пипетка цвета из изображения — Русский
Bildfarbwähler — Deutsch
Pengambil Warna Gambar — Bahasa Indonesia
Selector de color de imagen — Español
Công cụ lấy mã màu từ ảnh — Tiếng Việt
เครื่องมือดึงสีจากภาพ — ไทย
Pipeta kolorów ze zdjęcia — Polski
Görsel Renk Seçici — Türkçe
Selettore di colore da immagine — Italiano
Seletor de cor de imagem — Português
Afbeelding kleurenkiezer — Nederlands
Піпетка кольору із зображення — Українська

Counting text is harder than it looks (especially once Chinese and emoji show up)

Joe Lin — Wed, 26 Aug 2026 13:00:02 +0000

I used to think a word counter was the most boring tool imaginable. Split on spaces, maybe trim a newline, done.

That illusion lasted right up until I had to handle Chinese text, mixed Chinese+English text, and emoji in the same input box. Once you do that, even the question "what counts as one character?" stops being obvious.

"Word count" breaks the moment spaces stop meaning words

The core decision in this tool is that it doesn't treat every language like English. Instead of assuming whitespace-separated words are the main unit, it checks how much of the input is CJK and switches the highlighted metric when that ratio gets high enough:

const CJK_RANGE =
  /[⺀-⻿぀-ヿ㐀-䶿一-鿿豈-﫿가-힣]/;

const cjkCharCount = computed(
  () => graphemes.value.filter((ch) => CJK_RANGE.test(ch)).length,
);

const isCjkDominant = computed(() => {
  const nonSpace = charCountNoSpaces.value;
  if (nonSpace === 0) return false;
  return cjkCharCount.value / nonSpace >= 0.35;
});

const wordCount = computed(() => {
  const trimmed = (inputText.value || "").trim();
  if (!trimmed) return 0;
  return trimmed.split(/\s+/).filter(Boolean).length;
});

That 0.35 threshold is the interesting part. The tool is not trying to do true linguistic segmentation. It's making a practical UI decision: if enough of the non-space characters are CJK, then "characters" is probably the more honest primary unit than "words."

That's also why mixed text behaves reasonably. A sentence like 今天 shipping fix to prod still shows both numbers, but the tool decides which one deserves the visual emphasis instead of pretending one rule fits every script.

It avoids the classic JavaScript `.length` trap — mostly

If this were using plain string .length, emoji and other non-BMP characters would get overcounted because JavaScript strings are UTF-16 under the hood. The component explicitly avoids that:

const graphemes = computed(() => Array.from(inputText.value || ""));

const charCountWithSpaces = computed(() => graphemes.value.length);

const charCountNoSpaces = computed(
  () => graphemes.value.filter((ch) => !/\s/.test(ch)).length,
);

Array.from() iterates by Unicode code point, which is already much better than counting UTF-16 code units. A single 😀 won't accidentally become 2 characters.

I also like that the no-space count is derived from the same array instead of from a second regex-heavy pass over the raw string. It keeps the counting model consistent: first normalize into countable units, then filter those units.

Reading time, sentences, and paragraphs are all heuristics too

The tool doesn't just count text units. It also changes the reading-time formula depending on the detected script, and it uses lightweight regex rules for sentences and paragraphs:

const CJK_CHARS_PER_MINUTE = 300;
const WORDS_PER_MINUTE = 200;

const readingTimeSeconds = computed(() => {
  if (isCjkDominant.value) {
    return Math.ceil((charCountNoSpaces.value / CJK_CHARS_PER_MINUTE) * 60);
  }
  return Math.ceil((wordCount.value / WORDS_PER_MINUTE) * 60);
});

const sentenceCount = computed(() => {
  const trimmed = (inputText.value || "").trim();
  if (!trimmed) return 0;
  return trimmed
    .split(/[.!?。！？…]+/)
    .map((s) => s.trim())
    .filter(Boolean).length;
});

const paragraphCount = computed(() => {
  const text = inputText.value || "";
  if (!text.trim()) return 0;
  return text
    .split(/\n\s*\n+/)
    .map((s) => s.trim())
    .filter(Boolean).length;
});

This is the part I think most counters quietly hand-wave away. "Reading time" is not a universal constant, and even sentence counting depends on punctuation conventions. Here the code at least makes the tradeoff explicit: CJK gets characters-per-minute, space-delimited languages get words-per-minute, and paragraphs mean blank-line-separated blocks.

Where it still gets fuzzy

There are a couple of honest limitations in the current implementation.

First, graphemes is a slightly misleading variable name. Array.from() counts code points, not full grapheme clusters. That means some visually single characters — like family emoji, flags, or emoji plus skin-tone modifiers — can still count as more than one.

Second, sentence splitting is intentionally simple. A regex like /[.!?。！？…]+/ will also split on things that are not really sentence boundaries, like 3.14 or e.g.. And the CJK detection threshold is still a heuristic, so a mixed-language paragraph near 35% can flip the "primary" unit in a way that feels a little arbitrary.

I wrapped that logic into a small free tool: Word & Character Counter.

Available in other languages

字數字元計數器 — 繁體中文
字数字符计数器 — 简体中文
Word & Character Counter — English
文字数・文字カウンター — 日本語
글자수·단어수 카운터 — 한국어
Compteur de mots et de caractères — Français
Счётчик слов и символов — Русский
Wörter- und Zeichenzähler — Deutsch
Penghitung Kata dan Karakter — Bahasa Indonesia
Contador de Palabras y Caracteres — Español
Công Cụ Đếm Từ và Ký Tự — Tiếng Việt
เครื่องมือนับคำและตัวอักษร — ไทย
Licznik Słów i Znaków — Polski
Kelime ve Karakter Sayacı — Türkçe
Contatore di Parole e Caratteri — Italiano
Contador de Palavras e Caracteres — Português
Woorden- en Tekenteller — Nederlands
Рахувач Слів і Символів — Українська

I expected image pixelation to mean per-pixel math — this tool mostly just redraws the same rectangle twice

Joe Lin — Tue, 25 Aug 2026 13:00:03 +0000

The first time I looked at a "blur or mosaic just part of a photo" tool, I assumed the hard part would be the image-processing math.

In this implementation, the more interesting part is actually not a giant manual pixel loop. The mosaic effect is mostly a neat canvas trick: draw the selected region smaller, then scale it back up with smoothing disabled. The blur path is different again — it leans on the browser's built-in canvas filter, but only inside a clipped rectangle.

Pixelation is just aggressive downscaling, then scaling back up

The mosaic path doesn't average pixel blocks manually. Instead, it converts the selected area into a tiny temporary canvas, then stretches that tiny version back over the original rectangle:

const mosaicBlockSize = (intensity) =>
  Math.max(2, Math.round(2 + (intensity / 100) * 48));

function applyMosaicEffect(ctx, img, rect, intensity) {
  const { x, y, w, h } = rect;
  const blockSize = mosaicBlockSize(intensity);
  const smallW = Math.max(1, Math.round(w / blockSize));
  const smallH = Math.max(1, Math.round(h / blockSize));
  const tmp = document.createElement("canvas");
  tmp.width = smallW;
  tmp.height = smallH;
  const tctx = tmp.getContext("2d");
  tctx.drawImage(img, x, y, w, h, 0, 0, smallW, smallH);
  ctx.save();
  ctx.imageSmoothingEnabled = false;
  ctx.drawImage(tmp, 0, 0, smallW, smallH, x, y, w, h);
  ctx.restore();
}

That's a nice shortcut because the browser handles the resampling work for you. The important detail is ctx.imageSmoothingEnabled = false; without that, the enlarged blocks would get softened and you'd end up with a muddy blur instead of crisp square mosaic cells.

The intensity slider is also mapped to a concrete block size, not some vague "strength" value. At 100, the block size goes much larger, so the region becomes unreadable fast.

Blur uses the browser's filter pipeline, but only inside the selected box

Blur is handled very differently. There isn't a custom convolution kernel in the component at all. The code clips the canvas to the selected rectangle, turns on a blur filter, then redraws the source image:

const blurRadiusPx = (intensity) =>
  Math.max(1, Math.round(1 + (intensity / 100) * 40));

function applyBlurEffect(ctx, img, rect, intensity, naturalW, naturalH) {
  const { x, y, w, h } = rect;
  const radius = blurRadiusPx(intensity);
  ctx.save();
  ctx.beginPath();
  ctx.rect(x, y, w, h);
  ctx.clip();
  ctx.filter = `blur(${radius}px)`;
  ctx.drawImage(img, 0, 0, naturalW, naturalH);
  ctx.filter = "none";
  ctx.restore();
}

The subtle part here is the order: the full image is redrawn while the clip is active. That means only the selected area gets the blurred redraw, and everything outside the rectangle stays untouched from the first base draw.

I like this approach because it avoids writing and maintaining a manual blur implementation. The tradeoff is that you're trusting browser canvas filter performance, which is usually fine, but can get expensive on very large images.

The selection UI is really a coordinate-conversion problem

Drawing a box over an image sounds simple until the displayed image size changes. This component keeps the visible selection boxes in stage coordinates, then converts them back to original-image coordinates right before rendering:

const scale = computed(() =>
  naturalWidth.value && stageWidth.value ? stageWidth.value / naturalWidth.value : 1
);

const rectNatural = {
  x: box.x / s,
  y: box.y / s,
  w: box.w / s,
  h: box.h / s,
};

That only works because the stage image preserves aspect ratio (width: 100%; height: auto;), so one scale factor is enough.

The other smart bit is that the boxes are rescaled when the rendered image size changes:

const handleStageResize = (newW, newH) => {
  const fx = newW / oldW;
  const fy = newH / oldH;
  boxes.forEach((box) => {
    box.x *= fx;
    box.w *= fx;
    box.y *= fy;
    box.h *= fy;
  });
};

Without that ResizeObserver-driven update, responsive layout changes would make the selection overlay drift away from the actual content.

Where this gets tricky: preview cost and reversibility

Dragging a box updates state constantly, so the component doesn't render immediately on every pointer event. It schedules one redraw with requestAnimationFrame:

function scheduleRender() {
  if (rafId) return;
  rafId = requestAnimationFrame(() => {
    rafId = null;
    renderNow();
  });
}

Then renderNow() redraws the original image onto a full-resolution canvas and reapplies every box in natural-image coordinates. That's the right tradeoff for visual correctness: the downloaded image matches the preview because both come from the same canvas pipeline, not from CSS effects layered over the DOM.

The gotcha is cost. canvas.width = naturalWidth.value means preview rendering always happens at the image's original resolution. That's great for output quality, but a huge phone photo plus several blur regions can turn every drag into a lot of work. Also, blur is not the same as destruction: strong pixelation throws away more information, while blur can sometimes be partially reversed in principle. If you need something harder to recover, mosaic is the safer option.

I turned that approach into a small free tool here: Photo Blur & Pixelate Tool.

Available in other languages

照片打馬賽克／模糊工具 — 繁體中文
照片打马赛克／模糊工具 — 简体中文
Photo Blur & Pixelate Tool — English
写真モザイク・ぼかし加工ツール — 日本語
사진 모자이크·블러 처리 도구 — 한국어
Outil de Flou et Pixellisation de Photo — Français
Пикселизация и Размытие Фото — Русский
Foto Verpixeln & Unscharf Machen — Deutsch
Alat Sensor & Blur Foto — Bahasa Indonesia
Pixelar y Difuminar Fotos — Español
Công Cụ Làm Mờ/Che Pixel Ảnh — Tiếng Việt
เครื่องมือเบลอ/พิกเซลรูปภาพ — ไทย
Pikselizacja i Rozmycie Zdjęć — Polski
Fotoğraf Bulanıklaştırma ve Pikselleştirme — Türkçe
Pixelare e Sfocare Foto — Italiano
Pixelizar e Desfocar Fotos — Português
Foto Vervagen & Pixeleren — Nederlands
Розмиття та Пікселізація Фото — Українська

Browser OCR got a lot better once I stopped feeding Tesseract the raw image

Joe Lin — Mon, 24 Aug 2026 13:00:01 +0000

I assumed an image-to-text tool would be a very thin wrapper around Tesseract: upload a file, call recognize(), dump the text, done.

That version technically worked. It was also the kind of "works" that immediately annoys people: first run felt frozen, the wrong language silently trashed accuracy, and low-contrast screenshots produced junk even when the text looked readable to me.

What ended up mattering most wasn't some exotic OCR trick. It was making sure the browser OCR engine gets the right pixels, loads at the right time, and reports what it's doing while it warms up.

The OCR engine is loaded lazily, not at page startup

The tool is a Vue page, but the OCR engine is tesseract.js, which means WebAssembly plus a worker. Loading that eagerly would be wasteful, and in an SSR-ish setup it's also the kind of dependency you don't want touching the server bundle unless the user actually starts recognition.

So the OCR import happens inside the click handler:

const startRecognition = async () => {
  if (!previewCanvasEl.value || !naturalWidth.value) return;
  isRecognizing.value = true;
  progressPercent.value = 0;
  progressStatusText.value = t("imageOcrTextExtractor.statusPreparing");

  try {
    const { createWorker } = await import("tesseract.js");
    const worker = await createWorker(selectedLang.value, 1, {
      logger: (m) => {
        if (m && m.status) {
          progressStatusText.value = mapStatusText(m.status);
          progressPercent.value = Math.round((m.progress || 0) * 100);
        }
      },
    });
    activeWorker = worker;

    const { data } = await worker.recognize(previewCanvasEl.value);
    resultText.value = data && data.text ? data.text.trim() : "";
    await worker.terminate();
    activeWorker = null;
  } catch (err) {
    message.error({ content: t("imageOcrTextExtractor.errorRecognizeFailed") });
  }
};

Two practical things are happening here.

First, await import("tesseract.js") keeps the heavy OCR dependency out of the initial page path. Second, the logger callback turns Tesseract's internal status events into a real progress bar instead of a dead-looking button. That's especially important because the first run may need to fetch the language model before recognition even starts.

The preview canvas is also the OCR input, which is the right trade-off

The most useful implementation detail in this tool is that it doesn't preprocess a hidden copy and OCR the original file anyway. It draws the image onto a canvas, applies the optional filters there, and then sends that exact canvas to Tesseract.

function renderCanvas() {
  if (!imgEl.value || !previewCanvasEl.value || !naturalWidth.value) return;
  const canvas = previewCanvasEl.value;
  canvas.width = naturalWidth.value;
  canvas.height = naturalHeight.value;
  const ctx = canvas.getContext("2d");
  ctx.drawImage(imgEl.value, 0, 0, naturalWidth.value, naturalHeight.value);

  if (grayscaleEnabled.value || contrastEnabled.value) {
    const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
    const data = imageData.data;
    const c = 55;
    const factor = (259 * (c + 255)) / (255 * (259 - c));
    for (let i = 0; i < data.length; i += 4) {
      let r = data[i];
      let g = data[i + 1];
      let b = data[i + 2];
      if (grayscaleEnabled.value) {
        const avg = 0.299 * r + 0.587 * g + 0.114 * b;
        r = avg;
        g = avg;
        b = avg;
      }
      if (contrastEnabled.value) {
        r = clampByte(factor * (r - 128) + 128);
        g = clampByte(factor * (g - 128) + 128);
        b = clampByte(factor * (b - 128) + 128);
      }
      data[i] = r;
      data[i + 1] = g;
      data[i + 2] = b;
    }
    ctx.putImageData(imageData, 0, 0);
  }
}

That means the user can see the same grayscale / contrast-adjusted pixels the OCR engine is about to read. For OCR tools, that feedback loop matters a lot more than people think. If the text gets clearer after preprocessing, the user immediately understands why accuracy improves. If it gets worse, they can turn the option back off before wasting another run.

Also: this is intentionally simple preprocessing. No deskewing, no denoising pipeline, no adaptive thresholding. Just a luminance-based grayscale pass and a fixed contrast boost. For a browser tool, that's a reasonable speed/benefit trade-off.

Language selection is treated as OCR configuration, not UI decoration

One subtle bug with multilingual OCR tools is assuming the page locale and the image language are the same thing. This component avoids that by making the OCR language an explicit control, even though it defaults from the current site locale:

const tessLangMap = {
  tw: "chi_tra",
  cn: "chi_sim",
  en: "eng",
  jp: "jpn",
  fr: "fra",
  ru: "rus",
  kr: "kor",
  th: "tha",
  de: "deu",
  id: "ind",
  es: "spa",
  vi: "vie",
  pl: "pol",
  tr: "tur",
  it: "ita",
  pt: "por",
  nl: "nld",
  uk: "ukr",
};

const selectedLang = ref(tessLangMap[locale.value] || "eng");

That looks small, but it's one of the highest-impact decisions in the whole tool. OCR quality drops fast when the engine is loaded with the wrong language data, especially for scripts like Traditional Chinese, Simplified Chinese, Japanese, Korean, or Thai where character shapes and segmentation rules differ a lot from Latin text.

The UI copy in the language file even spells this out: the text language in the image is not necessarily the same as the website language. That's exactly the kind of thing users need to be told, because otherwise they blame the OCR engine for what is really a configuration mistake.

The honest limitations

This implementation is solid, but it's also refreshingly honest about what it does not do.

It only accepts jpeg, jpg, png, webp, and bmp. No PDF pipeline, no TIFF, no camera RAW.
The preprocessing is basic. It can help faint text and messy backgrounds, but it won't fix rotation, perspective distortion, motion blur, or handwriting.
The result uses data.text.trim() and stops there. The tool doesn't surface word boxes, line geometry, or confidence scores, even though those would be useful for debugging weak OCR output.
First use can still feel slow because language data has to be loaded before recognition begins. The progress bar helps, but it doesn't make the download disappear.

I like this kind of constraint, honestly. It keeps the tool focused on the common case: screenshots, photos, and scans where you mainly want copyable text without sending the image to a server. I turned that into a small free tool here: Image to Text OCR Tool.

Available in other languages

圖片文字辨識OCR工具 — 繁體中文
图片文字识别OCR工具 — 简体中文
Image to Text OCR Tool — English
画像文字認識OCRツール — 日本語
이미지 텍스트 인식 OCR 도구 — 한국어
Outil OCR Image en Texte — Français
Распознавание текста с изображений (OCR) — Русский
Bild-zu-Text OCR-Tool — Deutsch
Alat OCR Gambar ke Teks — Bahasa Indonesia
Herramienta OCR de Imagen a Texto — Español
Công cụ OCR Chuyển Ảnh Sang Văn Bản — Tiếng Việt
เครื่องมือ OCR แปลงรูปภาพเป็นข้อความ — ไทย
Narzędzie OCR Obraz na Tekst — Polski
Görselden Metne OCR Aracı — Türkçe
Strumento OCR da Immagine a Testo — Italiano
Ferramenta OCR de Imagem para Texto — Português
Afbeelding naar Tekst OCR-tool — Nederlands
Розпізнавання тексту з зображень (OCR) — Українська

The hard part of an image cropper is keeping two coordinate systems from drifting apart

Joe Lin — Sun, 23 Aug 2026 13:00:03 +0000

The first time I built an image cropper, I assumed the interesting part would be canvas.drawImage(). It wasn't. The thing that actually kept biting me was much less glamorous: the crop rectangle the user drags lives in display pixels, but the image you export has to be cut from the original source pixels.

If those two coordinate systems drift even a little, the preview looks right but the downloaded file comes out slightly off. That's the part this tool's Vue component is really solving.

The crop box is in CSS pixels, but the output has to use natural pixels

On screen, the crop box is just an absolutely positioned overlay on top of a responsive <img>. The exported image, though, needs source coordinates from the original file. So the component keeps the draggable box in stage-space, then converts it back into source-space with a scale factor:

const scale = computed(() =>
  naturalWidth.value && stageWidth.value ? stageWidth.value / naturalWidth.value : 1
);

const cropNatural = computed(() => {
  const s = scale.value || 1;
  return {
    x: box.x / s,
    y: box.y / s,
    w: box.w / s,
    h: box.h / s,
  };
});

That box object is what the user is dragging around visually. cropNatural is what eventually gets fed into drawImage(). I like this split because it keeps pointer math simple while still exporting the real pixels, not whatever scaled-down version happened to fit the page.

A subtle detail here: the code only uses a single width-based scale factor. That works because the image is rendered with width: 100% and height: auto, so X and Y scale uniformly.

Responsive layouts can quietly break cropping unless you rescale the box too

A cropper inside a flexible layout has another annoying problem: the displayed image can resize after load. Maybe the viewport changes, maybe the right-hand controls wrap, maybe the user rotates a phone. If the crop box stays at its old pixel coordinates, it's now pointing at the wrong part of the image.

This component fixes that with a ResizeObserver plus proportional remapping:

const handleStageResize = (newW, newH) => {
  if (!boxInitialized) {
    stageWidth.value = newW;
    stageHeight.value = newH;
    box.x = 0;
    box.y = 0;
    box.w = newW;
    box.h = newH;
    boxInitialized = true;
  } else {
    const oldW = stageWidth.value;
    const oldH = stageHeight.value;
    if (oldW > 0 && oldH > 0 && (newW !== oldW || newH !== oldH)) {
      const fx = newW / oldW;
      const fy = newH / oldH;
      box.x *= fx;
      box.w *= fx;
      box.y *= fy;
      box.h *= fy;
    }
    stageWidth.value = newW;
    stageHeight.value = newH;
  }
  scheduleRender();
};

This is the kind of code you don't notice when it's present, and immediately notice when it's missing. Instead of resetting the selection on resize, it preserves the same relative crop region. That's a much better feel on mobile and on responsive pages.

Aspect-ratio-locked resize handles are much branchier than they look

Freeform dragging is easy. Ratio-locked dragging is where the cropper stops being a rectangle and starts becoming geometry homework.

The code handles edges and corners differently:

if (ratio) {
  let newW = right - left;
  let newH = bottom - top;
  if (handle === "n" || handle === "s") {
    newW = newH * ratio;
    const cx = x + w / 2;
    left = cx - newW / 2;
    right = cx + newW / 2;
  } else if (handle === "e" || handle === "w") {
    newH = newW / ratio;
    const cy = y + h / 2;
    top = cy - newH / 2;
    bottom = cy + newH / 2;
  } else {
    newH = newW / ratio;
    if (handle.includes("n")) top = bottom - newH;
    else bottom = top + newH;
  }
}

That split is doing real UI work:

dragging top/bottom keeps the horizontal center stable
dragging left/right keeps the vertical center stable
dragging a corner treats one corner as the anchor and derives the other dimension from the ratio

Without those branches, ratio presets like 1:1, 16:9, or the 35×45 ID-photo preset feel weird immediately, because the box "slides" while you resize it.

Preview and export share the same pipeline, which keeps the tool honest

The live preview canvas isn't using some approximation. It's rendering the same crop coordinates and target dimensions that the download step uses:

function scheduleRender() {
  if (rafId) return;
  rafId = requestAnimationFrame(() => {
    rafId = null;
    renderPreviewNow();
  });
}

function renderPreviewNow() {
  const w = Math.max(1, Math.round(targetWidth.value));
  const h = Math.max(1, Math.round(targetHeight.value));
  canvas.width = w;
  canvas.height = h;
  const ctx = canvas.getContext("2d");
  if (format.value === "jpeg") {
    ctx.fillStyle = "#ffffff";
    ctx.fillRect(0, 0, w, h);
  }
  const cn = cropNatural.value;
  ctx.drawImage(imgEl.value, cn.x, cn.y, cn.w, cn.h, 0, 0, w, h);
}

Two nice implementation details here:

First, preview rendering is throttled with requestAnimationFrame(), which matters because pointermove can fire a lot while you're dragging handles around.

Second, JPEG output gets a white background fill before drawing. That's important because JPEG has no alpha channel; without the fill, transparent areas would be flattened unpredictably.

Where this still has sharp edges

The big technical assumption is that one scale factor is enough. Right now that's valid because the displayed image uses width: 100% and height: auto. If the UI ever changed to letterbox the image, apply transforms, or otherwise scale X and Y differently, box.x / scale would stop mapping cleanly back to source pixels.

There's also no explicit EXIF-orientation normalization in this component. In practice that's usually fine because browsers decode most phone photos the way users expect, but the cropper is trusting the browser's interpretation rather than normalizing image data itself.

I turned that implementation into a small free tool if you want to try it without wiring up the pointer math yourself: Image Cropper & Resizer.

Available in other languages

圖片裁切／縮圖尺寸調整工具 — 繁體中文
图片裁切／缩图尺寸调整工具 — 简体中文
Image Cropper & Resizer — English
画像トリミング＆リサイズツール — 日本語
이미지 자르기 및 크기 조절 도구 — 한국어
Recadrage & Redimensionnement d'Image — Français
Обрезка и изменение размера изображений — Русский
Bild zuschneiden & Größe ändern — Deutsch
Alat Crop & Resize Gambar — Bahasa Indonesia
Recortar y Redimensionar Imágenes — Español
Công Cụ Cắt & Đổi Kích Thước Ảnh — Tiếng Việt
เครื่องมือครอปและปรับขนาดรูปภาพ — ไทย
Przycinanie i Zmiana Rozmiaru Obrazu — Polski
Görsel Kırpma ve Boyutlandırma Aracı — Türkçe
Ritaglia e Ridimensiona Immagini — Italiano
Recortar e Redimensionar Imagens — Português
Afbeelding Bijsnijden & Formaat Wijzigen — Nederlands
Обрізка та зміна розміру зображень — Українська

East Asian nominal age isn't just age + 1 (the real boundary is Lunar New Year)

Joe Lin — Sat, 22 Aug 2026 13:00:03 +0000

I thought an age/zodiac calculator would be mostly date arithmetic until I got to East Asian nominal age (虛歲). That's the part where the obvious shortcut — currentYear - birthYear + 1 — looks right just often enough to fool you.

The real problem is that both nominal age and the Chinese zodiac roll over on Lunar New Year, not on January 1, and definitely not on your birthday. If someone is born near late January or early February, the naive formula is wrong in exactly the cases people care about most.

The whole thing hinges on a real Chinese New Year table

The Vue component doesn't try to "calculate" Lunar New Year from first principles. It ships a lookup table for 1930–2050 and treats that as the source of truth:

const LUNAR_NEW_YEAR = {
  2023: "01-22", 2024: "02-10", 2025: "01-29", 2026: "02-17",
  // ...every year from 1930 to 2050
};

function getCny(year) {
  const raw = LUNAR_NEW_YEAR[year];
  if (!raw) return null;
  const [m, d] = raw.split("-").map(Number);
  return { m, d };
}

function lunarYearLabel(year, month, day) {
  const cny = getCny(year);
  if (!cny) return null;
  if (month > cny.m || (month === cny.m && day >= cny.d)) {
    return year;
  }
  return year - 1;
}

That lunarYearLabel() helper is the key idea. A Gregorian date before that year's Lunar New Year still belongs to the previous lunar year label. So 2025-01-28 is still lunar year 2024, while 2025-01-29 flips to lunar year 2025. That's why nominal age is not just age + 1.

One lunar-year label powers both nominal age and zodiac

What I liked here is that the component doesn't implement separate edge-case logic for nominal age and zodiac. It computes the same lunar-year label for the birth date and for "today," then reuses that everywhere:

const nominalAgeInfo = computed(() => {
  const birthLabel = lunarYearLabel(by, bm, bd);
  const todayLabel = lunarYearLabel(ty, tm, td);
  return { age: todayLabel - birthLabel + 1, mode: "precise" };
});

And for the zodiac:

let label = by;

if (hasFullDate.value && tableReady) {
  const computedLabel = lunarYearLabel(by, bm, bd);
  if (computedLabel !== null) {
    label = computedLabel;
    mode = "precise";
  }
}

const idx = (((label - ZODIAC_REF_YEAR) % 12) + 12) % 12;
const key = zodiacKeys[idx];

That shared helper prevents a nasty class of bugs where your nominal age says one thing but your zodiac silently uses Jan 1 as the boundary and says another. The code also generates a visible zodiac range from one Lunar New Year to the day before the next one, which is a nice way to make the boundary explicit instead of hiding it behind a single animal name.

Star signs are simpler, except Capricorn crosses the year boundary

Western zodiac logic is much more boring — which is good — but there is still one non-obvious branch. Most signs live entirely inside the same calendar year, while Capricorn runs from December 22 to January 19:

function findWesternZodiac(bm, bd) {
  for (const z of westernZodiacTable) {
    const [sm, sd] = z.start;
    const [em, ed] = z.end;
    if (sm <= em) {
      if ((bm === sm && bd >= sd) || (bm > sm && bm < em) || (bm === em && bd <= ed)) {
        return z;
      }
    } else {
      // Capricorn: 12/22 ~ 1/19
      if ((bm === sm && bd >= sd) || (bm === em && bd <= ed)) {
        return z;
      }
    }
  }
  return null;
}

Without that sm <= em split, December/January signs get awkward fast. This is also why the tool requires a full month/day for star signs, while age and zodiac can fall back to rougher estimates from year-only input.

The gotchas are real

A couple of details in the code are honestly worth surfacing:

The "precise" Lunar New Year logic only works inside the built-in 1930–2050 table. Outside that range, the component deliberately falls back to year difference + 1 and shows a warning instead of pretending to know more than it does.
Leap-day birthdays are tricky. The birthday countdown uses new Date(currentYear, bm - 1, bd), so a Feb 29 birthday in a non-leap year normalizes to March 1 in JavaScript.
The day input is constrained by a computed maxDayInMonth, with leap years handled explicitly, so the UI won't let you keep something like February 31 selected after changing month/year.

I turned this into a small free tool if you want to inspect the behavior without reimplementing the lunar-year edge cases yourself: Age / East Asian Age / Chinese Zodiac / Star Sign Calculator.

Available in other languages

年齡／虛歲／生肖／星座即時計算機 — 繁體中文
年龄／虚岁／生肖／星座即时计算器 — 简体中文
Age / East Asian Age / Chinese Zodiac / Star Sign Calculator — English
年齢／数え年／干支／星座リアルタイム計算機 — 日本語
나이／세는나이／십이지신(띠)／별자리 실시간 계산기 — 한국어
Calculateur d'Âge / Âge Asiatique / Zodiaque Chinois / Signe Astrologique — Français
Калькулятор возраста / восточноазиатского возраста / китайского зодиака / знака зодиака — Русский
Alter / Ostasiatisches Alter / Chinesisches Tierkreiszeichen / Sternzeichen Rechner — Deutsch
Kalkulator Usia / Usia Asia Timur / Shio / Zodiak Real-Time — Bahasa Indonesia
Calculadora de Edad / Edad Asiática / Zodiaco Chino / Signo del Horóscopo — Español
Máy Tính Tuổi Thật／Tuổi Âm／Con Giáp／Cung Hoàng Đạo Trực Tiếp — Tiếng Việt
เครื่องคำนวณอายุ／อายุจีน／นักษัตรจีน／ราศี แบบเรียลไทม์ — ไทย
Kalkulator Wieku / Wieku Wschodnioazjatyckiego / Chińskiego Zodiaku / Znaku Zodiaku — Polski
Yaş / Doğu Asya Yaşı / Çin Burcu / Batı Burcu Hesaplayıcı — Türkçe
Calcolatrice Età / Età Est-Asiatica / Zodiaco Cinese / Segno Zodiacale — Italiano
Calculadora de Idade / Idade Asiática / Zodíaco Chinês / Signo do Zodíaco — Português
Leeftijd / Oost-Aziatische Leeftijd / Chinese Dierenriem / Sterrenbeeld Calculator — Nederlands
Калькулятор віку / східноазійського віку / китайського зодіаку / знаку зодіаку — Українська

Kaomoji aren't a special format — they're just Unicode strings (and that changes how a copy-paste tool works)

Joe Lin — Fri, 21 Aug 2026 13:00:02 +0000

A while back I noticed that most “special character” pages are really just giant dumps of glyphs. That works until you mix →, ♥, 😀, and ¯\\_(ツ)_/¯ in the same interface. One of those is a single symbol, one is an emoji, and one is basically a tiny string drawing made out of regular characters.

When I built a copy-paste collection for them, the interesting part wasn't the list itself. It was figuring out how to make one-character symbols and full kaomoji behave like the same kind of data without turning the UI into a mess.

The useful abstraction is just `{ char, kw }`

The core data structure is intentionally boring. Every item becomes an object with the visible text and a keyword slug:

const toSymbols = (list) => list.map(([char, kw]) => ({ char, kw }));

const rawKaomoji = [
  ["(´・ω・`)", "happy"],
  ["(╯°□°）╯︵ ┻━┻", "table-flip"],
  ["¯\\_(ツ)_/¯", "shrug"],
];

const categories = [
  { id: "arrows", symbols: toSymbols(rawArrows) },
  { id: "kaomoji", symbols: toSymbols(rawKaomoji) },
  { id: "emoji", symbols: toSymbols(rawEmoji) },
];

That sounds trivial, but it's the reason the page can treat a right-arrow and a table-flip face with the same button component. Kaomoji aren't a special rich-text format here. They're just strings made from ordinary Unicode characters, stored the same way as everything else.

There's even a comment in the component noting that the symbol content itself doesn't need per-item translation — only the category labels go through i18n. That's a good fit for this kind of dataset: the glyphs are the product, and the UI chrome is what's language-specific.

Search stops caring about categories the moment you type

The page has category tabs, but search switches the mental model from “browse one bucket” to “scan everything”:

const visibleSymbols = computed(() => {
  if (isSearching.value) {
    const kw = searchKeyword.value.trim().toLowerCase();
    const result = [];
    categories.forEach((cat) => {
      cat.symbols.forEach((item) => {
        if (item.kw.indexOf(kw) > -1 || item.char === searchKeyword.value.trim()) {
          result.push(item);
        }
      });
    });
    return result;
  }
  return activeCategoryObj.value.symbols;
});

I like this because it's deliberately simple. No extra search index, no special handling per category, no separate kaomoji parser. Every category participates in the same linear scan, and exact-character matching means you can paste a symbol into the box and find that exact entry back.

That simplicity also explains the keyword design. The internal search terms are slugs like arrow-right, heart-outline, and table-flip, so the component can stay small and predictable.

Kaomoji force you to think about layout, not just data

A symbol picker looks easy right up until you remember that some “symbols” are ten-plus characters long. The component handles that with a tiny font-size heuristic:

function symbolFontSize(char) {
  const len = (char || "").length;
  if (len <= 2) return "26px";
  if (len <= 4) return "20px";
  if (len <= 8) return "15px";
  return "12px";
}

Then each button applies it directly:

<button
  class="symbolBtn"
  :style="{ fontSize: symbolFontSize(item.char) }"
  @click="copySymbol(item.char)"
>
  {{ item.char }}
</button>

That keeps arrows and hearts large, while shrinking long kaomoji enough to fit the same grid. The CSS backs it up with word-break: break-word, white-space: normal, and a centered grid cell, which is exactly the kind of boring UI detail that makes this sort of tool feel usable instead of chaotic.

Copying text reliably still needs a fallback path

The copy logic doesn't assume the modern Clipboard API will always work:

function copySymbol(char) {
  if (!char) return;

  if (navigator.clipboard && navigator.clipboard.writeText) {
    navigator.clipboard.writeText(char).catch(() => fallbackCopy(char));
  } else {
    fallbackCopy(char);
  }

  message.success({ content: t("specialCharEmojiCopy.copiedToast") });
  addToRecent(char);
}

And the fallback is the old hidden-textarea + document.execCommand("copy") pattern. That isn't glamorous, but it matters for compatibility.

The same section also keeps a recent-history list in localStorage, capped at 20 items and deduplicated by moving the latest copied symbol to the front. It even wraps storage reads/writes in try/catch, which is worth doing because browsers can block localStorage or hand you corrupted data.

Where this still gets weird

A few honest gotchas come with this territory:

Clipboard writes can still fail depending on browser permissions, context, or legacy API support. The fallback helps, but execCommand("copy") is still legacy behavior.
The sizing heuristic uses JavaScript string .length, which counts UTF-16 code units, not visual graphemes. For complex emoji sequences, the “length” the code sees is not always the number a human would expect.
Search is intentionally lightweight: it matches internal keyword slugs or an exact symbol string. That's simple and fast, but it's not the same thing as full multilingual semantic search.
Rendering is platform-dependent. These are text characters, not images, so the same emoji or symbol can look surprisingly different across fonts and operating systems.

I turned that into a small free tool here: Special Characters & Kaomoji Copy Paste. It ended up being less about “emoji” and more about treating lots of different Unicode text shapes as one copyable interface.

Available in other languages

特殊符號與顏文字一鍵複製大全 — 繁體中文
特殊符号与颜文字一键复制大全 — 简体中文
Special Characters & Kaomoji Copy Paste — English
特殊記号・顔文字コピペ辞典 — 日本語
특수문자·카오모지 복사 모음 — 한국어
Caractères Spéciaux & Kaomoji à Copier-Coller — Français
Специальные символы и каомодзи — копировать и вставлять — Русский
Sonderzeichen & Kaomoji zum Kopieren — Deutsch
Simbol Spesial & Kaomoji Copy Paste — Bahasa Indonesia
Caracteres Especiales y Kaomoji para Copiar y Pegar — Español
Ký Tự Đặc Biệt & Kaomoji Sao Chép Dán — Tiếng Việt
สัญลักษณ์พิเศษและคาโอโมจิ คัดลอกวาง — ไทย
Znaki Specjalne i Kaomoji do Kopiowania — Polski
Özel Karakterler ve Kaomoji Kopyala Yapıştır — Türkçe
Caratteri Speciali e Kaomoji da Copiare — Italiano
Caracteres Especiais e Kaomoji para Copiar e Colar — Português
Speciale Tekens & Kaomoji om te Kopiëren — Nederlands
Спеціальні символи та каомодзі — копіювати і вставляти — Українська

Random pairing gets surprisingly tricky once you try to avoid repeats

Joe Lin — Thu, 20 Aug 2026 13:00:03 +0000

I thought a "random pairing" tool would be a half-hour job. Shuffle a list, take names two at a time, done.

The annoying part only showed up when I tried to make it usable for recurring things like coffee chats, book clubs, and gift exchanges. "Random" is easy. "Random, but please stop giving me the same pairings as last month" is where the implementation stops being trivial.

The input cleanup is doing more than it looks like

The first thing the component does is normalize the pasted list into a deduplicated array:

const namesList = computed(() => {
  const tokens = rawNames.value
    .split(/[\n,，;；]+/g)
    .map((s) => s.trim())
    .filter(Boolean);
  return [...new Set(tokens)];
});

I like this because it fixes the boring real-world mess up front. People paste one name per line, or comma-separated, or full-width Chinese punctuation, and the tool accepts all of it. Trimming plus filter(Boolean) also prevents blank lines from turning into fake participants.

The more opinionated part is new Set(tokens). That means exact duplicate names are silently collapsed before any pairing happens. For a lot of office or classroom lists that's the right default, because duplicates are usually copy-paste mistakes. But it also means two different people both named Alex would be treated as one person unless the user distinguishes them manually.

The pairing logic avoids the classic "one person left over" bug

The shuffle itself is the standard Fisher-Yates pattern:

function shuffle(arr) {
  const a = [...arr];
  for (let i = a.length - 1; i > 0; i--) {
    const j = Math.floor(Math.random() * (i + 1));
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}

That part is conventional. The more interesting bit is what happens after the shuffle:

function buildPairingUnits(shuffled) {
  const units = [];
  const n = shuffled.length;
  let i = 0;
  let idx = 1;
  while (i < n) {
    if (n - i === 3) {
      units.push({ id: idx++, members: shuffled.slice(i, i + 3), isTrio: true });
      i += 3;
    } else {
      units.push({ id: idx++, members: shuffled.slice(i, i + 2), isTrio: false });
      i += 2;
    }
  }
  return units;
}

Instead of producing pairs until one unlucky person is stranded, it watches for the "exactly 3 left" case and turns that into a trio. That's a small rule, but it's the difference between a usable recurring tool and a toy demo. Nobody gets dropped, and the UI can explicitly label the result as a three-person unit.

Grouping by size is really balancing by remainder

The grouping mode has a subtle implementation detail I didn't expect at first. Even when the user picks "group by size", the code doesn't just keep slicing fixed chunks and dump leftovers into a tiny final group:

if (groupSizeMode.value === "byCount") {
  const k = Math.max(1, Math.min(n, Math.floor(groupCountInput.value) || 1));
  const base = Math.floor(n / k);
  const remainder = n % k;
  sizes = Array.from({ length: k }, (_, i) => base + (i < remainder ? 1 : 0));
} else {
  const s = Math.max(1, Math.floor(groupSizeInput.value) || 1);
  const k = Math.max(1, Math.round(n / s) || Math.ceil(n / s));
  const base = Math.floor(n / k);
  const remainder = n % k;
  sizes = Array.from({ length: k }, (_, i) => base + (i < remainder ? 1 : 0));
}

The key idea is that both modes end up distributing the remainder across groups as evenly as possible. So if you have 10 people and ask for groups of 3, you don't get 3,3,3,1; you get something closer to 4,3,3. That feels much fairer in practice, especially for workshops or discussion groups where a lonely one-person leftover would be obviously wrong.

"Avoid repeats" is implemented as a search problem, not a hard rule

The smartest part of the tool is that it doesn't store only exact past groups. It breaks every result into pairwise co-occurrences:

function pairKey(a, b) {
  return [a, b].sort().join("___");
}

function coOccurrencePairsOfUnits(units) {
  const keys = [];
  for (const u of units) {
    const members = u.members;
    for (let a = 0; a < members.length; a++) {
      for (let b = a + 1; b < members.length; b++) {
        keys.push(pairKey(members[a], members[b]));
      }
    }
  }
  return keys;
}

That design matters a lot. In grouping mode, the history is still tracking "who has already been together," not just "was this exact four-person group repeated." That's a much better definition of fairness for recurring rotations.

Then, instead of pretending repeats can always be avoided, the component tries up to 300 random draws and keeps the one with the fewest historical conflicts:

const MAX_ATTEMPTS = 300;
let best = null;
for (let i = 0; i < MAX_ATTEMPTS; i++) {
  const attempt = generateAttempt();
  if (!best || attempt.conflicts < best.conflicts) best = attempt;
  if (attempt.conflicts === 0) break;
}

I like this tradeoff. It's honest about the math: with a small fixed roster, eventually you run out of unseen pairings. So the goal becomes "minimize repeats" rather than "guarantee perfection." For a client-side tool, 300 attempts is also cheap enough to feel instant.

The gotchas are real

There are a few limitations here that are worth saying out loud:

History is stored in localStorage, so it's tied to one browser on one device. Clear browser data or switch laptops, and the pairing memory is gone.
saveHistoryStore() intentionally fails silently if storage is blocked or full. That's good for not breaking the UI, but it also means users may think history was saved when the browser refused it.
The "best of 300 attempts" approach is a heuristic, not a proof of optimality. It usually finds a low-conflict result, but it isn't solving the pairing problem exhaustively.
Exact duplicate names are deduplicated. That's nice for accidental repeats, but not for two distinct humans with the same displayed name.

I turned that into a small free tool here: Fair Random Pairing & Grouping Generator.

Available in other languages

公平隨機配對／分組產生器 — 繁體中文
公平随机配对／分组生成器 — 简体中文
Fair Random Pairing & Grouping Generator — English
公平ランダムペア・グループ分けツール — 日本語
공정한 랜덤 짝짓기·조 나누기 생성기 — 한국어
Générateur de paires/groupes aléatoires équitables — Français
Генератор случайных пар и групп — Русский
Fairer Zufalls-Paarungs- & Gruppengenerator — Deutsch
Generator Pasangan/Grup Acak yang Adil — Bahasa Indonesia
Generador de Parejas/Grupos Aleatorios Justos — Español
Công cụ Ghép Đôi/Chia Nhóm Ngẫu Nhiên Công Bằng — Tiếng Việt
ตัวสุ่มจับคู่/แบ่งกลุ่มอย่างเป็นธรรม — ไทย
Generator Sprawiedliwych Losowych Par/Grup — Polski
Geçmişi Hatırlayan Adil Rastgele Eşleştirme/Gruplama Aracı — Türkçe
Generatore di Coppie/Gruppi Casuali Equi — Italiano
Gerador de Pares/Grupos Aleatórios Justos — Português
Eerlijke Willekeurige Koppel-/Groepsgenerator — Nederlands
Генератор випадкових пар і груп — Українська

Why pasted text keeps breaking search and formatting (and the regexes I ended up using to clean it)

Joe Lin — Wed, 19 Aug 2026 07:00:04 +0000

I kept running into a boring problem that was harder to debug than it should have been: text that looked normal, but behaved wrong the moment I pasted it into a CMS, a spreadsheet, or a code comment. Search would fail. Line breaks would get weird. A heading copied from ChatGPT would drag Markdown markers along with it. Sometimes the only visible clue was that the punctuation felt slightly "off."

What finally made this manageable wasn't some big NLP trick. It was going back to the dumb, reliable layer: exact character matching. The tool I built for this is basically a pile of small, deterministic cleanups for the specific junk that copied text tends to accumulate — full-width punctuation mixed into ASCII, invisible Unicode code points, curly quotes, em dashes, leftover Markdown, and whitespace noise.

The most useful part is the invisible-character scan, not the cleaning

The piece I trust most in the whole component is the part that explicitly names which invisible characters it cares about, then counts them by code point. It's not doing a vague "this text seems suspicious" pass. It has a hard-coded inventory:

const invisibleDefs = [
  { key: "zwsp", codes: [0x200b] },
  { key: "zwnj", codes: [0x200c] },
  { key: "zwj", codes: [0x200d] },
  { key: "bomZwnbsp", codes: [0xfeff] },
  { key: "wordJoiner", codes: [0x2060] },
  { key: "softHyphen", codes: [0x00ad] },
  { key: "bidiMarks", codes: [0x200e, 0x200f, 0x202a, 0x202b, 0x202c, 0x202d, 0x202e] },
];

const codesToRegex = (codes) =>
  new RegExp(`[${codes.map((c) => "\\u" + c.toString(16).padStart(4, "0")).join("")}]`, "g");

const analyzeInvisible = (str) => {
  const breakdown = invisibleDefs.map((def) => ({
    key: def.key,
    count: (str.match(codesToRegex(def.codes)) || []).length,
  }));
  const total = breakdown.reduce((sum, row) => sum + row.count, 0);
  return { breakdown, total };
};

I like this because it's brutally literal. U+200B isn't treated the same as U+FEFF, and bidi control marks are grouped together on purpose instead of disappearing into one generic "hidden char" bucket. That matters when you're trying to answer why text is broken, not just make it stop being broken.

It also explains why this kind of cleaner is more useful than asking an AI model to "clean up my text." LLMs are decent at rewriting sentences, but they are famously shaky at exact character-level accounting. This component is just matching code points and counting hits. If there are three soft hyphens and one BOM, it tells you there are three soft hyphens and one BOM.

A nice touch in the Vue code is that the UI doesn't just show one scary total. It filters the breakdown so only categories with nonzero counts are shown. That makes the result read like a diagnosis instead of a dump.

Full-width and half-width normalization is just a code-point offset — with a very deliberate boundary

The width-normalization logic is much simpler than most people expect:

const FULLWIDTH_CHARS_REGEX = /[！-～]/g;
const HALFWIDTH_CHARS_REGEX = /[\x21-\x7E]/g;

const toHalfWidth = (str) =>
  str.replace(FULLWIDTH_CHARS_REGEX, (ch) => String.fromCharCode(ch.charCodeAt(0) - 0xfee0));
const toFullWidth = (str) =>
  str.replace(HALFWIDTH_CHARS_REGEX, (ch) => String.fromCharCode(ch.charCodeAt(0) + 0xfee0));

That 0xFEE0 offset is the whole trick. For the visible ASCII range, the full-width forms in Unicode are laid out at a fixed distance from their half-width counterparts, so the conversion can be a straight subtraction or addition.

The interesting part is what the regexes don't include. This is not a general "normalize all East Asian width weirdness" function. It only targets visible ASCII-style characters: full-width ！ through ～, and half-width ! through ~. That means it intentionally leaves Chinese, Japanese, and Korean characters alone, which is the right safety tradeoff for a text cleaner.

But it also means a few things people might assume are covered are not. Ordinary spaces are excluded from the half-width regex, so converting "to full-width" does not turn spaces into full-width spaces. And the ideographic space U+3000 is outside this logic entirely. So the implementation is conservative, not comprehensive.

One other subtle detail: the detection count for width issues depends on the selected direction. In the computed stats, the tool counts either full-width characters that would be collapsed to ASCII, or ASCII characters that would be expanded to full-width. That's actually a good fit for the UI, because the count answers "how many characters will this mode change?" rather than some fuzzier question about how mixed the text feels.

The "AI artifact" cleanup is really a few blunt regex passes, applied in order

The part marketed as AI-copy-paste cleanup isn't a magical classifier. It's a small collection of explicit transforms:

const SMART_QUOTES_REGEX = /[“”‘’]/g;
const fixSmartQuotes = (str) =>
  str.replace(/[“”]/g, '"').replace(/[‘’]/g, "'");

const DASH_REGEX = /[—–]/g;
const fixDashes = (str) => str.replace(DASH_REGEX, "-");

const MARKDOWN_PATTERNS = [
  /\*\*(.+?)\*\*/g,
  /__(.+?)__/g,
  /`([^`]+)`/g,
  /^#{1,6}\s+/gm,
  /^[ \t]*[-*+]\s+/gm,
  /^>\s+/gm,
];

const fixMarkdown = (str) =>
  str
    .replace(/\*\*(.+?)\*\*/g, "$1")
    .replace(/__(.+?)__/g, "$1")
    .replace(/`([^`]+)`/g, "$1")
    .replace(/^#{1,6}\s+/gm, "")
    .replace(/^[ \t]*[-*+]\s+/gm, "")
    .replace(/^>\s+/gm, "");

I actually prefer this to something smarter-sounding. The source is honest about what it does: curly quotes become straight quotes, em/en dashes become -, and a narrow set of Markdown markers get stripped while preserving the text they wrap.

After that, the component does a whitespace pass: repeated ASCII spaces collapse to one, runs of three or more newlines collapse to two, and every line gets trim() applied. The order matters, and the code tracks counts on the current text at each stage:

if (options.aiArtifacts) {
  if (options.smartQuotes) {
    aiApplied += countSmartQuotes(text);
    text = fixSmartQuotes(text);
  }
  if (options.dashes) {
    aiApplied += countDashes(text);
    text = fixDashes(text);
  }
  if (options.markdown) {
    aiApplied += countMarkdown(text);
    text = fixMarkdown(text);
  }
}

if (options.whitespace) {
  if (options.collapseSpaces) {
    wsApplied += countCollapseSpaces(text);
    text = fixCollapseSpaces(text);
  }
  if (options.collapseBlankLines) {
    wsApplied += countCollapseBlankLines(text);
    text = fixCollapseBlankLines(text);
  }
  if (options.trimLines) {
    wsApplied += countTrimLines(text);
    text = fixTrimLines(text);
  }
}

That sounds minor, but I think it's the right design. The summary isn't just parroting the initial detection totals. It's reporting how many fixes each enabled stage actually applied after earlier stages had already mutated the text. So you don't get misleading double counts from a later pass operating on characters an earlier pass already removed.

Honest limitations and gotchas

The implementation is practical, but it definitely has edges.

The biggest one is the Markdown cleanup. It's intentionally lossy. If a line starts with #, >, or -, this tool assumes that marker is accidental formatting residue and strips it. Most of the time that's exactly what you want when pasting from a chat UI. But if your real content needs a leading hash, quote marker, or hyphen, this pass can be too aggressive.

It's also not a full Markdown parser, which is probably a good thing for a cleaner like this, but you can see the gaps. It handles **bold**, __bold__, inline backticks, ATX headings, unordered list markers, and blockquotes. It does not handle ordered lists, links, fenced code blocks, tables, or single-asterisk emphasis. So "Markdown cleanup" here really means "remove the handful of leftover markers I kept seeing in pasted text," not "round-trip arbitrary Markdown to plain text."

The width conversion has the same philosophy: safe and narrow. It won't touch CJK characters, which is good, but it also won't normalize ideographic spaces. If somebody expects this to solve every width-related typography issue in Unicode, it won't.

And the strangest detail in the whole component is probably the download behavior. The cleaner removes BOM characters from pasted input, but the TXT download function creates the blob with "" + outputText.value, which prepends a UTF-8 BOM back onto the saved file. I can see why — it makes the file open more reliably in some Windows apps — but it's worth knowing. If your definition of "clean" is "absolutely no U+FEFF anywhere," the copied output is cleaner than the downloaded file.

After running into these edge cases often enough, I turned this into a small free tool: Batch Text Format Cleaner. It runs entirely in the browser, which felt important for the kind of text people usually paste into something like this.

Available in other languages

批量文字格式標準化清理工具 — 繁體中文
批量文字格式标准化清理工具 — 简体中文
Batch Text Format Cleaner — English
一括テキスト整形クリーナー — 日本語
일괄 텍스트 서식 정리 도구 — 한국어
Nettoyeur de texte en masse — Français
Массовая очистка формата текста — Русский
Massen-Textformat-Bereiniger — Deutsch
Pembersih Format Teks Massal — Bahasa Indonesia
Limpiador de formato de texto en lote — Español
Công cụ dọn dẹp định dạng văn bản hàng loạt — Tiếng Việt
เครื่องมือล้างรูปแบบข้อความแบบกลุ่ม — ไทย
Masowy czyściciel formatowania tekstu — Polski
Toplu Metin Biçimi Temizleyici — Türkçe
Pulitore di formato testo in blocco — Italiano
Limpador de formato de texto em lote — Português
Bulk tekstopmaak schoonmaker — Nederlands
Масове очищення формату тексту — Українська

The hard part of batch date conversion isn't formatting — it's deciding what `01/02/2024` means

Joe Lin — Tue, 18 Aug 2026 13:00:03 +0000

I used to think a bulk date converter was basically a dropdown wrapped around a date library. Paste a bunch of rows, pick YYYY-MM-DD, done. Then you look at real exports from spreadsheets, CRMs, logs, and old internal tools and realize the problem isn't "formatting" at all.

It's triage.

Some rows are obvious. Some are malformed. Some have month names. Some came from a CSV with five unrelated columns. And then there's the classic cursed input: 01/02/2024, which is either January 2 or February 1 depending on who produced the file. The Vue component behind this tool is interesting because it doesn't pretend that ambiguity goes away if you call the right parser. It models that ambiguity explicitly.

It starts by assuming uploaded files are messy, not clean

One thing I liked in the source is that it doesn't treat file input as a single happy path. If you upload a TXT file, it works line by line. If the upload looks CSV-ish, it switches into a tiny parser and then tries to figure out which column is actually the date column.

The CSV split logic is manual instead of using a naive line.split(","), which matters because quoted commas are a real thing in exports:

const splitCsvLine = (line) => {
  const result = [];
  let cur = "";
  let inQuotes = false;
  for (let i = 0; i < line.length; i++) {
    const ch = line[i];
    if (ch === '"') {
      if (inQuotes && line[i + 1] === '"') {
        cur += '"';
        i++;
      } else {
        inQuotes = !inQuotes;
      }
    } else if (ch === "," && !inQuotes) {
      result.push(cur);
      cur = "";
    } else {
      cur += ch;
    }
  }
  result.push(cur);
  return result.map((s) => s.trim());
};

After that, it doesn't ask the user to map columns immediately. It scores each column by counting how many cells look like dates, then auto-selects the best candidate:

for (let c = 0; c < maxCols; c++) {
  const count = dataRows.filter((r) => isLikelyDateCell(r[c])).length;
  columns.push({ index: c, header: headerRow ? headerRow[c] : "" });
  if (count > bestCount) {
    bestCount = count;
    bestIdx = c;
  }
}

That's a small detail, but it matches how people actually use these tools. A lot of the time the date data is buried inside a broader export, and the nicest UX isn't magical parsing of the entire file — it's auto-picking the most plausible date column while still letting me override it.

There's also a quiet heuristic here I appreciate: if the first CSV row doesn't look like dates, the component treats it as a header row. Again, that feels very grounded in real data cleanup work instead of demo data.

The parser is layered, explicit, and much less trusting than `new Date()`

The core function is analyzeLine, and the good part is that it doesn't just throw every string at JavaScript date parsing and hope the runtime locale does something sensible. It walks through a few explicit cases.

First, strings that begin with a four-digit year get treated as ISO-like input, including slash and dot variants:

if (/^\d{4}[-/.]\d{1,2}[-/.]\d{1,2}/.test(s)) {
  const isoLike = s.replace(/\./g, "-").replace(/\//g, "-");
  let dt = DateTime.fromISO(isoLike);
  if (!dt.isValid) dt = DateTime.fromISO(s);
  if (dt.isValid) {
    return {
      kind: "final",
      dt,
      detected: "ISO 8601 / YYYY-MM-DD",
      ambiguous: false,
      order: null,
      hasTime: /\d{1,2}:\d{2}/.test(s),
    };
  }
}

Then it handles month-name formats using regex plus a hardcoded MONTH_MAP, and only after that falls back to purely numeric forms. That order matters. It means March 3, 2024 isn't left up to environment-dependent parsing; the code extracts the parts and builds a Luxon DateTime directly.

The numeric branch is where the real cleanup logic lives:

const pNum = /^(\d{1,4})[/\-.\s](\d{1,4})[/\-.\s](\d{2,4})(?:[T\s,]+(\d{1,2}):(\d{2})(?::(\d{2}))?)?$/;
const nm = s.match(pNum);
if (!nm) return { kind: "error", reason: "unrecognized" };

const g1 = nm[1], g2 = nm[2], g3 = nm[3];
const n1 = parseInt(g1, 10), n2 = parseInt(g2, 10), n3 = parseInt(g3, 10);

From there, the code checks whether the year is first or last, whether one of the remaining numbers is definitely too large to be a month, and whether the whole thing is genuinely valid once Luxon constructs a date object.

A subtle but very real implementation choice: two-digit years are normalized with a fixed cutoff. If the year string is two digits, 00 to 49 becomes 2000-2049, and 50 to 99 becomes 1950-1999. That's not "universal truth" — it's a product choice. I actually like seeing that choice made in code instead of buried inside a library default.

Ambiguous dates are a first-class state, not a hidden guess

This is the part that makes the tool feel honest.

If a numeric row can be proven to be DMY or MDY — say 31/12/2023 or 12/31/2023 — it gets parsed as a final answer immediately. But if both the day-ish and month-ish numbers are <= 12, the parser does not fake certainty. It returns a pending result and defers the decision.

The batch processor then counts unambiguous DMY and MDY rows and uses that as a majority-vote guess for the ambiguous ones:

let dmyCount = 0, mdyCount = 0;
analyzed.forEach(({ a }) => {
  if (a.kind === "final" && a.order === "DMY") dmyCount++;
  if (a.kind === "final" && a.order === "MDY") mdyCount++;
});
let globalGuess = null;
if (dmyCount > mdyCount) globalGuess = "DMY";
else if (mdyCount > dmyCount) globalGuess = "MDY";

And then, for each pending row:

if (forcedOrder === "dmy") {
  day = a.remA; month = a.remB; order = "DMY"; flagAmbiguous = false;
} else if (forcedOrder === "mdy") {
  month = a.remA; day = a.remB; order = "MDY"; flagAmbiguous = false;
} else if (globalGuess === "DMY") {
  day = a.remA; month = a.remB; order = "DMY"; flagAmbiguous = true;
} else if (globalGuess === "MDY") {
  month = a.remA; day = a.remB; order = "MDY"; flagAmbiguous = true;
} else {
  day = a.remA; month = a.remB; order = "DMY"; flagAmbiguous = true;
}

That last else is the important bit. If the batch has no reliable signal, the component still proceeds, but it defaults ambiguous rows to DMY and marks them as ambiguous. That's exactly the kind of tradeoff I want a bulk-cleanup tool to make. Keep the workflow moving, but don't pretend an unknowable row was knowable.

The UI follows through on that model too: the summary distinguishes successful rows, ambiguous rows, and outright errors, and there's a filter for showing only rows that need review. That's much better than burying the risky rows inside a wall of "success."

Output formatting is boring on purpose, which is the right call

Once the parser has turned a row into a real DateTime, the output stage is deliberately simple. The component has a small list of target formats, plus ISO 8601 and a custom Luxon format string:

const formatRowConverted = (row) => {
  if (row.status === "error" || !row.dt) return "";
  const opt = targetFormatOptions.find((o) => o.value === targetFormat.value) || targetFormatOptions[0];
  try {
    if (opt.isISO8601) {
      return row.hasTime ? row.dt.toISO({ suppressMilliseconds: true }) : row.dt.toISODate();
    }
    if (opt.isCustom) {
      return row.dt.toFormat(customFormat.value || "yyyy-MM-dd");
    }
    return row.dt.toFormat(opt.format);
  } catch (e) {
    return "#FORMAT_ERROR#";
  }
};

I like two things here. First, time is only preserved in ISO output if the original row actually had time data, tracked earlier as hasTime. Second, custom formatting is handed to Luxon directly instead of inventing yet another token system.

The rest of the pipeline stays client-side too. Copying uses a temporary textarea and document.execCommand("copy"); downloads are generated with Blob and URL.createObjectURL; CSV export escapes quotes and prepends a UTF-8 BOM so Excel is less likely to mangle it. Even the results table is paginated at 100 rows per page, which is a very practical browser-side detail when you paste a few thousand lines.

None of that is glamorous, but it's the stuff that makes a utility feel dependable instead of half-finished.

Honest limitations and gotchas

A few source-level limitations are worth saying out loud.

The biggest one is month names: this parser only recognizes English month text. The regex is [A-Za-z]{3,9} and the mapping is a hardcoded English MONTH_MAP, so March 3, 2024 works, but localized month names won't.

The majority-vote ambiguity logic is also narrower than it first sounds. The global guess only counts rows that were definitively identified as DMY or MDY. ISO-style rows and month-name rows don't contribute because their order is null. So if your file is mostly 2024-01-05 plus a few ambiguous 01/02/2024 rows, there may be no signal at all, and the fallback becomes DMY-with-warning.

Two-digit years are another opinionated corner. The 49 cutoff is reasonable, but it still means 03/04/49 and 03/04/50 land in different centuries. That's fine as long as you know it, and worth double-checking if you're cleaning genuinely old data.

And one smaller implementation detail: CSV detection starts with rawLines.some((l) => l.includes(",")). In practice that's usually fine, but it does mean "contains a comma somewhere" is enough to push the upload into CSV handling. That's a heuristic, not a formal file-type detector.

I turned this into a small free tool: Batch Date Format Converter. I mostly use it for spreadsheet exports where I trust the raw values just enough to want a deterministic cleanup pass before importing them anywhere else.

Available in other languages

批量日期格式轉換器 — 繁體中文
批量日期格式转换器 — 简体中文
Batch Date Format Converter — English
一括日付フォーマット変換ツール — 日本語
대량 날짜 형식 변환기 — 한국어
Convertisseur de formats de dates en masse — Français
Массовый конвертер форматов дат — Русский
Stapel-Datumsformat-Konverter — Deutsch
Konverter Format Tanggal Massal — Bahasa Indonesia
Conversor de formatos de fecha en lote — Español
Công cụ chuyển đổi định dạng ngày theo lô — Tiếng Việt
ตัวแปลงรูปแบบวันที่แบบกลุ่ม — ไทย
Konwerter formatów dat wsadowo — Polski
Toplu Tarih Formatı Dönüştürücü — Türkçe
Convertitore di formati data in blocco — Italiano
Conversor de formatos de data em lote — Português
Batch Datumformaat Converter — Nederlands
Масовий конвертер форматів дат — Українська

The fastest part of this fuzzy duplicate finder is the comparison it never does

Joe Lin — Tue, 18 Aug 2026 07:00:04 +0000

A while back I needed the annoying middle ground between exact dedupe and "just ask an AI." Not "remove rows that are byte-for-byte identical," but "tell me whether john.smith@example.com and jon.smith@example.com are probably the same person" — at list sizes where you actually want a deterministic answer, not a chatbot taking a best guess.

I assumed I'd end up reaching for embeddings or some search index. The Vue file for this tool is much more old-school than that, in a good way: normalize each line, compare strings with Levenshtein distance, skip huge chunks of impossible pairs before the expensive work starts, then merge the surviving matches into groups. Reading the source, the clever part isn't the fuzzy metric itself. It's how much work the component avoids.

The "ignore whitespace" switch is doing more than its name suggests

The normalization step is short, but it explains a lot of the tool's behavior:

const normalize = (str) => {
  let s = str;
  if (ignoreCase.value) s = s.toLowerCase();
  if (ignoreWhitespace.value) {
    s = s.replace(/\s+/g, " ").trim();
    s = s.replace(/[.,\-_/#!$%^&*;:=`~()"'·、，。]/g, "");
  }
  return s;
};

This is not semantic matching. It's still raw string comparison after a bit of cleanup. If the boxes are left at their defaults, the tool lowercases everything, collapses repeated whitespace, trims the ends, and removes a hand-picked set of punctuation characters.

That one regex is more important than it looks. It means Acme, Inc. and Acme Inc get closer because commas and periods disappear. But it also means the option labeled "ignore whitespace" is really "ignore whitespace plus some punctuation." And because the cleanup stops there, the tool does not know that Corp and Corporation are related tokens, or that St. and Street are the same word, or that accented characters should be folded together.

That matters when you look at the threshold math later. After normalization, john.smith@example.com vs jon.smith@example.com is one deletion away and scores extremely high. Acme Corp. vs Acme Corporation is a human-obvious near-duplicate, but as plain edit distance it's still a lot of edits apart. The component is honest about that: it doesn't pretend to understand abbreviations; it just compares cleaned strings.

The real performance trick is proving most pairs can never qualify

The tool says it can chew through thousands of rows in the browser, which sounds suspicious if you think "Levenshtein on every pair." The reason it gets away with it is that it doesn't actually do that.

First, it sorts the normalized entries by length. Then it uses the threshold to derive a hard upper bound on what lengths could still possibly match:

const order = items.map((_, idx) => idx).sort((a, b) => items[a].length - items[b].length);

const maxLenB = threshold > 0 ? Math.floor(lenA / threshold) : Infinity;
for (let oj = oi + 1; oj < order.length; oj++) {
  const j = order[oj];
  const textB = items[j];
  const lenB = textB.length;
  if (lenB > maxLenB) break;

  const maxLen = Math.max(lenA, lenB);
  const maxDist = Math.floor((1 - threshold) * maxLen);
  if (maxDist < Math.abs(lenA - lenB)) continue;
  // ...
}

The scoring formula later is 1 - dist / maxLen. So if your threshold is 80%, the edit distance has to be at most 20% of the longer string. But edit distance can never be smaller than the length gap alone — if one string is four characters longer, you're already on the hook for at least four insertions/deletions before you even think about substitutions.

That's why the length sort is such a good trick. Once lenB grows beyond Math.floor(lenA / threshold), every later string is also too long, so the loop can break entirely instead of just continue. The component turns "compare everything with everything" into "only compare pairs that are mathematically capable of clearing the threshold."

The Levenshtein implementation itself also bails out early:

function levDist(a, b, maxDist) {
  const la = a.length, lb = b.length;
  if (Math.abs(la - lb) > maxDist) return maxDist + 1;
  let prev = new Array(lb + 1);
  for (let j = 0; j <= lb; j++) prev[j] = j;
  for (let i = 1; i <= la; i++) {
    const curr = new Array(lb + 1);
    curr[0] = i;
    let rowMin = curr[0];
    const ca = a.charCodeAt(i - 1);
    for (let j = 1; j <= lb; j++) {
      const cost = ca === b.charCodeAt(j - 1) ? 0 : 1;
      const val = Math.min(prev[j] + 1, curr[j - 1] + 1, prev[j - 1] + cost);
      curr[j] = val;
      if (val < rowMin) rowMin = val;
    }
    if (rowMin > maxDist) return maxDist + 1;
    prev = curr;
  }
  return prev[lb];
}

That rowMin > maxDist check is the nice bit. As soon as a row in the dynamic-programming table proves there's no path back under the allowed distance budget, the function aborts. And all of this heavy work runs inside a Web Worker created from a Blob, so the page can keep updating a progress bar instead of freezing while the browser burns through comparisons.

The output groups are connected components, not pairwise cliques

Another implementation detail I wouldn't have guessed from the UI: the tool doesn't think in terms of "best match for each row." It builds a graph of successful pairs and then unions connected rows together.

edges.forEach((edge) => {
  const ra = find(edge[0]), rb = find(edge[1]);
  if (ra !== rb) parent[ra] = rb;
});

const groups = Object.keys(groupsMap)
  .map((root) => groupsMap[root])
  .filter((members) => members.length >= 2)
  .map((members) => ({
    indices: members,
    scores: members.map((m) => (bestScore[m] !== undefined ? bestScore[m] : 1)),
  }))
  .sort((a, b) => b.indices.length - a.indices.length);

Then, back on the main thread, it turns those indices back into original strings and shows each item with a single percentage badge:

members: g.indices
  .map((memberIdx, mi) => ({
    text: entries[memberIdx],
    score: Math.round(g.scores[mi] * 100),
  }))
  .sort((a, b) => b.score - a.score),

That means a "group" is really a connected component: if A is similar enough to B, and B is similar enough to C, all three land in one bucket even if A and C would not pass the threshold directly.

That behavior is probably what you want for cleanup work, because duplicate chains are common in real data. But it also creates a subtle interpretation trap: the percentage shown beside a row is that row's best edge anywhere in the group, not its similarity to every other row in the group, and not necessarily its similarity to the row displayed above it.

So a group can look tighter than it really is. A toy example at an 80% threshold is abcd, abcde, and abce: the middle string matches both neighbors at 80%, which is enough to union all three, even though abcd and abce are only 75% similar to each other. The source code is very clear on this once you notice the union-find step, but it isn't the kind of behavior users usually infer from a "similarity %" badge.

Honest gotchas

A few limitations fall straight out of the implementation, and I actually like that they're visible in the source instead of being hand-waved away.

First, the CSV upload path is intentionally lightweight, not a real CSV parser:

if (trimmed.includes(",")) {
  const first = trimmed.split(",")[0].trim();
  return first.replace(/^"(.*)"$/, "$1");
}

So it only keeps the first comma-separated chunk of each line. That's fine for simple one-column exports, but a quoted field like "Acme, Inc.",123 will get mangled because .split(",")[0] stops inside the quoted name.

Second, the distance function works on JavaScript UTF-16 code units (length and charCodeAt). That's perfectly fine for most Latin text, CJK, and the normal customer-name/address cases this tool is clearly aimed at. But emoji and other astral-plane characters count as two code units, so their edit distance can be a little less intuitive than a human would expect.

And third, the default 80% threshold is stricter than a lot of people assume. It catches typos beautifully; it does not magically understand business abbreviations. If your real problem is Co. vs Company, St vs Street, or domain-specific aliases, you'd need extra normalization rules before Levenshtein even starts.

I turned this into a small free tool if you want to throw a messy list at it without wiring up your own worker, distance matrix, and CSV export: Fuzzy Duplicate Finder.

Available in other languages

模糊重複比對工具 — 繁體中文
模糊重复比对工具 — 简体中文
Fuzzy Duplicate Finder — English
あいまい重複チェッカー — 日本語
유사 중복 검사기 — 한국어
Détecteur de doublons approximatifs — Français
Поиск нечётких дубликатов — Русский
Fuzzy-Duplikat-Finder — Deutsch
Pencari Duplikat Mirip (Fuzzy) — Bahasa Indonesia
Buscador de Duplicados Aproximados — Español
Công Cụ Tìm Trùng Lặp Gần Đúng — Tiếng Việt
เครื่องมือค้นหารายการซ้ำแบบคลุมเครือ — ไทย
Wyszukiwarka Podobnych Duplikatów — Polski
Bulanık Tekrar Bulucu — Türkçe
Rilevatore di Duplicati Approssimativi — Italiano
Localizador de Duplicados Aproximados — Português
Fuzzy Duplicaten Zoeker — Nederlands
Пошук нечітких дублікатів — Українська

I thought masking PII for AI prompts was a regex problem — the restore step was the real design constraint

Joe Lin — Mon, 17 Aug 2026 13:00:04 +0000

A while back I kept running into the same slightly awkward workflow: I wanted an AI model to help rewrite customer support text, summarize an internal note, or clean up something messy from a spreadsheet — but the input also contained real email addresses, phone numbers, IDs, and occasionally card-like numbers that absolutely should not be pasted raw into a third-party prompt.

My first instinct was the obvious one: just redact the sensitive bits with regex. But once I looked at the actual Vue code for this tool, the interesting part was not the detection at all. The hard requirement is reversibility. If an AI reply comes back with placeholders still embedded in the text, you need to restore the exact original values later, without losing track of duplicates, order, or overlaps.

That changes the problem a lot. This is not a "PII detector" so much as a local tokenization system with a downloadable mapping table.

The core idea is a reversible token table, not one-off redaction

The state in the component makes the design pretty explicit:

const inputText = ref("");
const maskedText = ref("");
const mappingList = ref([]); // [{ code, type, value }]
let maskCounter = 1;

const getOrCreateCode = (value, type) => {
  const existing = mappingList.value.find((e) => e.value === value);
  if (existing) return existing.code;
  const code = `[MASK_${maskCounter++}]`;
  mappingList.value.push({ code, type, value });
  return code;
};

That getOrCreateCode() detail matters more than it looks. The tool does not generate a fresh token for every match. If the same email address or phone number appears five times, it reuses the same [MASK_n] code for all of them because it keys the mapping by value.

I actually like that choice. It keeps the output smaller, and it also makes the AI-facing text more semantically consistent: the same real-world entity stays the same placeholder everywhere. If alice@example.com appears in three paragraphs, the restored output does not depend on positional bookkeeping. It just needs one mapping entry.

The tradeoff is that the mapping table is the whole system. If you lose it, the placeholders are just placeholders. The component keeps that table in memory until you export it, which is why the page also has a big warning banner and a JSON download step. Under the hood, the masking pass literally resets the current state and rebuilds everything from scratch:

const runAutoDetect = () => {
  if (!inputText.value.trim()) return;

  mappingList.value = [];
  maskCounter = 1;

  const matches = detectMatches(inputText.value);
  let result = "";
  let cursor = 0;

  matches.forEach((match) => {
    result += inputText.value.slice(cursor, match.start);
    result += getOrCreateCode(match.value, match.type);
    cursor = match.end;
  });

  result += inputText.value.slice(cursor);
  maskedText.value = result;
};

That also reveals one non-obvious product decision: re-running auto-detect blows away the old mapping table and any previous manual additions. In other words, the tool treats each detection run as a new masking session, not as an incremental editor.

Regex detection only works because the matches are prioritized and validated

The detection layer is rule-based, but it is not just a pile of regexes slapped onto a textarea. The component defines typed patterns in a specific priority order:

const patternDefs = [
  { type: "email", regex: /[a-zA-Z0-9.+_-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9.-]+/g },
  {
    type: "ip",
    regex: /\b(?:(?:25[0-5]|2[0-4]\d|1?\d?\d)\.){3}(?:25[0-5]|2[0-4]\d|1?\d?\d)\b/g,
  },
  { type: "ip", regex: /\b(?:[0-9a-fA-F]{1,4}:){2,7}[0-9a-fA-F]{1,4}\b/g },
  { type: "iban", regex: /\b[A-Za-z]{2}\d{2}[A-Za-z0-9]{10,30}\b/g },
  {
    type: "creditCard",
    regex: /\b(?:\d[ -]?){13,19}\b/g,
    validate: luhnCheck,
  },
  { type: "idPassport", regex: /\b\d{3}-\d{2}-\d{4}\b/g },
  { type: "idPassport", regex: /\b[A-Za-z][12]\d{8}\b/g },
  { type: "idPassport", regex: /\b[A-Z]{1,2}\d{6,8}\b/g },
  {
    type: "phone",
    regex: /(?:\+\d{1,3}[-.\s]?)?\(?\d{2,4}\)?[-.\s]?\d{3,4}[-.\s]?\d{3,4}(?:[-.\s]?\d{2,4})?/g,
    minDigits: 7,
  },
];

There are two pragmatic safeguards here that I think are easy to miss.

First, card-like numbers are not accepted on regex shape alone. They also pass through a Luhn check. That is a very practical way to cut down false positives when you are scanning arbitrary text containing long numeric strings.

Second, the tool does not blindly accept overlapping matches. It records every raw match with a priority index, sorts by priority, and then greedily accepts only the first non-overlapping span:

rawMatches.sort((a, b) => a.priority - b.priority || a.start - b.start);

const isOverlapping = (a, b) => a.start < b.end && b.start < a.end;
const accepted = [];
rawMatches.forEach((match) => {
  if (!accepted.some((acc) => isOverlapping(acc, match))) {
    accepted.push(match);
  }
});

accepted.sort((a, b) => a.start - b.start);
return accepted;

That is a small piece of code, but it is the reason the output stays sane. Broad patterns like phone numbers and generic passport-like IDs would otherwise happily collide with more specific patterns. By putting credit cards above phone numbers, for example, the component prefers the more specific interpretation when the spans overlap.

This is also where the implementation feels honest. It does not pretend to understand meaning. It understands formats. That is why the UI explicitly keeps a manual-marking path for names and other unstructured PII.

The restore flow is intentionally plain: JSON in, string replacement out

The privacy-sensitive part of this page is surprisingly unglamorous in a good way. I do not see any API request in the component for detection, export, import, or restore. The mapping table is downloaded with Blob/URL.createObjectURL(), uploaded back with FileReader, and applied with plain string replacement.

Export looks like this:

const payload = {
  version: 1,
  generatedAt: new Date().toISOString(),
  entries: mappingList.value.map(({ code, type, value }) => ({
    code,
    type,
    value,
  })),
};
const blob = new Blob([JSON.stringify(payload, null, 2)], {
  type: "application/json",
});

And restore is just as direct:

const parseMappingJson = (jsonStr) => {
  const parsed = JSON.parse(jsonStr);
  const entries = Array.isArray(parsed) ? parsed : parsed.entries;
  if (!Array.isArray(entries)) throw new Error("invalid mapping format");
  const cleaned = entries
    .filter((e) => e && e.code && typeof e.value !== "undefined")
    .map((e) => ({ code: e.code, type: e.type || "manual", value: e.value }));
  if (!cleaned.length) throw new Error("empty mapping");
  restoreMappingEntries.value = cleaned;
};

const runRestore = () => {
  let result = restoreInputText.value;
  restoreMappingEntries.value.forEach(({ code, value }) => {
    if (!code) return;
    result = result.split(code).join(value);
  });
  restoredText.value = result;
};

That is worth calling out because people often assume a tool like this must be doing something cryptographic behind the scenes. This one is not. It is much simpler than that: replace sensitive spans with stable tokens, keep a plaintext mapping table, and later substitute those tokens back.

For this use case, simplicity is probably a feature. There is less mystery about what happens to the data. The component is basically just local string processing plus a JSON file you are expected to keep yourself.

The honest gotchas are where the tool gets interesting

A few behaviors in the code are exactly the kind of thing I would want to know before trusting a workflow like this.

The first is that manual masking is global, not positional. The component grabs the selected substring, but then replaces it like this:

const selected = maskedText.value.slice(start, end);
const code = getOrCreateCode(selected, "manual");
maskedText.value = maskedText.value.split(selected).join(code);

So if I highlight one occurrence of John and click the manual button, every identical John in the whole textarea gets replaced, not just the one I selected. Sometimes that is exactly what you want. Sometimes it is a surprise.

The second is that "hide values" is only a UI preview state. The table view switches between full text and a shortened preview (ab••••yz style), but the real values still sit in mappingList in memory, and the exported JSON contains the raw data. That is fine, but it means this feature is about shoulder-surfing reduction, not actual cryptographic protection.

The third is the usual regex limitation, and the code more or less admits it. Structured formats like email, IPv4, IBAN, or card numbers are decent fits for rules. Names, addresses, free-form notes, and organization-specific identifiers are not. The tool handles that by giving you a manual fallback, not by pretending regex can solve entity recognition.

And finally, some of the patterns are intentionally broad. \b[A-Z]{1,2}\d{6,8}\b will catch some passport-like identifiers, but broad rules like that can also match things that only look like IDs in the right text. The Luhn check makes the credit-card pattern smarter; the generic ID patterns are still fundamentally shape-based.

That is probably the right compromise for a small client-side utility. I would rather a tool like this be transparent about being rule-based than oversell itself as "AI privacy" magic.

I turned that idea into a small free tool here: PII Mask & Restore Tool. I mostly use it when I want help rewriting or structuring text for an AI prompt without sending the raw personal details in the same message.

Available in other languages

敏感資料遮罩還原工具 — 繁體中文
敏感数据遮罩还原工具 — 简体中文
PII Mask & Restore Tool — English
個人情報マスキング＆復元ツール — 日本語
개인정보 마스킹 및 복원 도구 — 한국어
Outil de masquage et restauration des données PII — Français
Маскировка и восстановление персональных данных — Русский
PII-Maskierungs- und Wiederherstellungstool — Deutsch
Alat Masking & Restore Data Pribadi — Bahasa Indonesia
Herramienta de Enmascarado y Restauración de Datos Personales — Español
Công cụ Che giấu & Khôi phục Dữ liệu Cá nhân — Tiếng Việt
เครื่องมือปกปิดและกู้คืนข้อมูลส่วนบุคคล — ไทย
Narzędzie do maskowania i przywracania danych osobowych — Polski
Kişisel Veri Maskeleme ve Geri Yükleme Aracı — Türkçe
Strumento di Mascheramento e Ripristino Dati Personali — Italiano
Ferramenta de Mascaramento e Restauração de Dados Pessoais — Português
Tool voor Maskeren en Herstellen van Persoonsgegevens — Nederlands
Інструмент маскування та відновлення персональних даних — Українська

DEV Community: BeGoodTool.com

Why a precise image color picker needs two canvases (one to read pixels, one to draw the loupe)

The real job is mapping cursor space back to image space

The loupe isn't CSS zoom — it's a second canvas with smoothing disabled

Every picked pixel gets normalized into HEX, RGB, and HSL immediately

The gotchas are mostly about pixels not meaning what you think they mean

Available in other languages

Counting text is harder than it looks (especially once Chinese and emoji show up)

"Word count" breaks the moment spaces stop meaning words

It avoids the classic JavaScript .length trap — mostly

Reading time, sentences, and paragraphs are all heuristics too

Where it still gets fuzzy

Available in other languages

I expected image pixelation to mean per-pixel math — this tool mostly just redraws the same rectangle twice

Pixelation is just aggressive downscaling, then scaling back up

Blur uses the browser's filter pipeline, but only inside the selected box

The selection UI is really a coordinate-conversion problem

Where this gets tricky: preview cost and reversibility

Available in other languages

Browser OCR got a lot better once I stopped feeding Tesseract the raw image

The OCR engine is loaded lazily, not at page startup

The preview canvas is also the OCR input, which is the right trade-off

Language selection is treated as OCR configuration, not UI decoration

The honest limitations

Available in other languages

The hard part of an image cropper is keeping two coordinate systems from drifting apart

The crop box is in CSS pixels, but the output has to use natural pixels

Responsive layouts can quietly break cropping unless you rescale the box too

Aspect-ratio-locked resize handles are much branchier than they look

Preview and export share the same pipeline, which keeps the tool honest

Where this still has sharp edges

Available in other languages

East Asian nominal age isn't just age + 1 (the real boundary is Lunar New Year)

The whole thing hinges on a real Chinese New Year table

One lunar-year label powers both nominal age and zodiac

Star signs are simpler, except Capricorn crosses the year boundary

The gotchas are real

Available in other languages

Kaomoji aren't a special format — they're just Unicode strings (and that changes how a copy-paste tool works)

The useful abstraction is just { char, kw }

Search stops caring about categories the moment you type

Kaomoji force you to think about layout, not just data

Copying text reliably still needs a fallback path

Where this still gets weird

Available in other languages

Random pairing gets surprisingly tricky once you try to avoid repeats

The input cleanup is doing more than it looks like

The pairing logic avoids the classic "one person left over" bug

Grouping by size is really balancing by remainder

"Avoid repeats" is implemented as a search problem, not a hard rule

The gotchas are real

Available in other languages

Why pasted text keeps breaking search and formatting (and the regexes I ended up using to clean it)

The most useful part is the invisible-character scan, not the cleaning

Full-width and half-width normalization is just a code-point offset — with a very deliberate boundary

The "AI artifact" cleanup is really a few blunt regex passes, applied in order

Honest limitations and gotchas

Available in other languages

The hard part of batch date conversion isn't formatting — it's deciding what `01/02/2024` means

It starts by assuming uploaded files are messy, not clean

The parser is layered, explicit, and much less trusting than new Date()

Ambiguous dates are a first-class state, not a hidden guess

Output formatting is boring on purpose, which is the right call

Honest limitations and gotchas

Available in other languages

The fastest part of this fuzzy duplicate finder is the comparison it never does

The "ignore whitespace" switch is doing more than its name suggests

The real performance trick is proving most pairs can never qualify

The output groups are connected components, not pairwise cliques

Honest gotchas

Available in other languages

I thought masking PII for AI prompts was a regex problem — the restore step was the real design constraint

The core idea is a reversible token table, not one-off redaction

Regex detection only works because the matches are prioritized and validated

The restore flow is intentionally plain: JSON in, string replacement out

The honest gotchas are where the tool gets interesting

Available in other languages

It avoids the classic JavaScript `.length` trap — mostly

The useful abstraction is just `{ char, kw }`

The parser is layered, explicit, and much less trusting than `new Date()`