DEV Community: Ahnhyeongkyu

I Built a Testimonial.to Alternative — Here's What I Learned

Ahnhyeongkyu — Mon, 13 Apr 2026 18:02:53 +0000

I've been shipping products for a while now — StatMate, RoastSite, CodeNeat, RestInLight, and a few others. Every single one of them had the same problem: I'd get great feedback from users in DMs and emails, but none of it was visible on my landing pages.

I looked at Testimonial.to. Great product, $2.4M ARR, clearly solving a real problem. But three things bugged me:

The widget was heavy. Loading a 50KB+ widget to show three quotes felt wrong.
CSS conflicts were constant. Their widget styles would clash with my Tailwind setup.
No intelligence layer. All testimonials were treated equally.

So I built Trustfolio. Here's the technical story.

Shadow DOM for Style Isolation

If you've ever embedded a third-party widget on your site, you know the CSS collision nightmare. Shadow DOM solves this completely. The widget renders inside an encapsulated DOM tree with its own scoped styles. Zero leakage in either direction.

The result: embed one line of code, and the widget looks exactly the same on every site, regardless of what CSS framework the host page uses.

The Sub-5KB Challenge

Competitors ship 50-125KB widget bundles. Ours is under 5KB. How?

No framework runtime (vanilla JS, no React/Vue/Svelte)
No CSS-in-JS library
No external font loading
Aggressive tree-shaking and minification
Single IIFE bundle, zero external dependencies

AI Conversion Scoring

This is the experimental part. Every testimonial gets analyzed on ingestion:

Sentiment detection — genuine enthusiasm vs. polite filler
Specificity scoring — "saved 10 hours/week" scores higher than "great tool"
Conversion prediction — 0-100 score based on specificity + emotion + outcome mentions

Where I Am Now

Product is live at trustfolio.dev
Free tier: 15 testimonials, full AI features
Pro: $29/mo, Business: $79/mo
Using it on all my own products (dogfooding)

What I'd love feedback on: Is AI conversion scoring genuinely useful, or is it solving a problem that doesn't exist?

Happy to answer any technical questions in the comments.

I Built 8 Developer Tools That Never See Your Code

Ahnhyeongkyu — Sun, 12 Apr 2026 22:59:28 +0000

The Moment I Realized the Problem

A few months ago, I was debugging a production issue at midnight. I had a large JSON config file that was not parsing correctly. I did what every developer does — I opened the first Google result for "json formatter online" and pasted my config.

Then it hit me. That config contained database connection strings, API keys, and internal service URLs. I opened DevTools and checked the Network tab.

Sure enough: a POST request carrying my entire input to the site's server. My production credentials had just traveled across the internet to a server I knew nothing about.

I checked three more popular formatting sites. Same pattern. Every one of them sent the input to their backend for processing.

This Is Not a Theoretical Risk

Think about what developers paste into online tools on a daily basis:

JSON files containing API keys, database credentials, and service configurations
Base64 strings that encode authentication tokens and binary data
SQL queries revealing table names, column structures, and business logic
JWTs containing user identities, roles, and session data
Regex patterns tested against real production data
Code diffs showing proprietary source code changes

The leading online developer tool sites handle tens of millions of visits per month. That is an enormous volume of sensitive developer data flowing through third-party servers every day.

And here is the thing: none of these operations require a server. JSON formatting, Base64 encoding, URL encoding, regex matching, text diffing, JWT decoding, SQL formatting, hash generation — all of these can be done entirely in the browser with JavaScript.

So I Built CodeNeat

CodeNeat is a set of 8 developer tools where every operation runs 100% in your browser. No data is ever sent to any server for processing.

The 8 Tools

1. JSON Formatter & Viewer
Format, validate, minify, and explore JSON with syntax highlighting and interactive tree view.

2. Base64 Encode/Decode
Encode and decode Base64 strings. Instant results with zero server round-trip.

3. URL Encode/Decode
Full Unicode support for URL encoding and decoding.

4. Regex Tester
Real-time matching with capture groups and flag controls.

5. Diff Checker
Side-by-side text comparison with line-level highlighting.

6. JWT Decoder
Decode and inspect JWTs — header, payload, signature, expiration.

7. SQL Formatter
Multi-dialect SQL formatting. Your queries never leave the browser.

8. Hash Generator
MD5, SHA-1, SHA-256, SHA-512. All computation via Web Crypto API.

How It Works

Each tool is a pure TypeScript function in lib/tools/:

// lib/tools/json.ts
export function formatJson(input: string, indent: number = 2): string {
  const parsed = JSON.parse(input);
  return JSON.stringify(parsed, null, indent);
}

These functions are imported directly into React client components. No fetch(). No XMLHttpRequest. No server endpoint.

How to Verify

Method 1: DevTools

Open any tool on codeneat.dev, open DevTools Network tab, filter by Fetch/XHR, use the tool. Zero processing requests.

Method 2: Offline

Load any tool, disconnect from the internet, use the tool. It works because the processing never needed a server.

Method 3: Source Code

Open source: github.com/Ahnhyeongkyu/codeneat. Search for fetch( in lib/tools/. Zero results.

The Stack

Framework: Next.js 16 with App Router
Language: TypeScript
Styling: Tailwind CSS v4 + shadcn/ui
Deployment: Vercel
License: MIT

What Is Next

A Chrome extension that brings these tools into the browser toolbar. The core logic ports directly since it is pure functions.

Try It

codeneat.dev — free, no account required.

If useful: Star on GitHub to help others discover it.

Your code should stay yours. That is not a feature — it should be the default.

Stop Shipping 300KB Testimonial Widgets — There's a Better Way

Ahnhyeongkyu — Sat, 28 Mar 2026 04:29:09 +0000

If you've ever added a testimonial widget to your site, you probably noticed the performance hit. Most popular solutions load 200-300KB of JavaScript, inject iframes, and tank your Core Web Vitals.

I run five different web products. Every one of them needed social proof. And every testimonial tool I tried made the same trade-off: nice-looking widgets that quietly destroyed page speed.

So I built Trustfolio.

The Problem

Here's what a typical testimonial widget does to your site:

200-300KB of JavaScript loaded on every page
Layout shift from async-loaded content
Extra DNS lookups and third-party connections
No way to know which testimonials actually drive conversions

How Trustfolio Is Different

1. Under 5KB Widget

The entire embed script is under 5KB gzipped. It uses Shadow DOM for style isolation, loads async, and renders in under 100ms. Zero layout shift.

<div data-trustfolio="YOUR_WIDGET_ID"></div>
<script src="https://trustfolio.dev/embed.js" async></script>

That's it. Two lines. No iframes, no external CSS, no layout shift.

2. AI That Knows What Converts

Instead of manually picking which testimonials to show, Trustfolio's AI analyzes every submission:

Sentiment Analysis — scores emotional tone from 0 to 1
Smart Highlights — finds the most persuasive phrases automatically
Conversion Score — rates each testimonial 0-100 based on how likely it is to drive action
Auto-Tagging — categorizes by topic (support, pricing, features, etc.)

3. Six Widget Layouts

Layout	Best For
Wall of Love	Landing pages, dedicated testimonial sections
Carousel	Limited space, above the fold
Badge	Compact trust signals
Single Card	Hero sections, sidebars
Popup	Exit intent, time-delayed social proof
Marquee	Continuous scrolling banners

4. Multiple Collection Methods

Custom collection pages — branded forms with your questions
Import from CSV — migrate from other tools
Google/G2 imports — pull existing reviews (more sources coming)

Technical Architecture

Next.js 16 with Edge Runtime for the OG image API
Neon (serverless Postgres) via Drizzle ORM
Shadow DOM (closed mode) for widget style isolation
sendBeacon for analytics tracking without blocking
AI analysis powered by Claude API

Pricing

Free: 10 testimonials, 1 widget, wall layout
Pro ($29/mo): Unlimited testimonials, all layouts, AI analysis
Business ($79/mo): Everything + API access, white label, A/B testing

Try It

If you're running a SaaS, portfolio, or any site that shows customer feedback, give it a shot: trustfolio.dev

Free tier is genuinely usable — no credit card, no trial expiration. I'd appreciate any feedback from the dev community.

I Built a Sub-5KB Testimonial Widget Because Every Alternative Tanked My Lighthouse Score

Ahnhyeongkyu — Fri, 27 Mar 2026 11:51:25 +0000

Every testimonial widget I tried added 200-500KB to my pages. My Lighthouse scores dropped. My ads got more expensive because pages loaded slower.

So I built Trustfolio — a testimonial platform where the entire embed widget is under 5KB gzipped.

The Problem

Most testimonial tools treat performance as an afterthought. They load heavy JavaScript bundles, inject their own CSS that conflicts with yours, and add hundreds of milliseconds to your page load.

Research shows each second of delay reduces conversions by 4.42%. If you're running paid ads, slow pages = wasted ad spend.

What I Built

Trustfolio is a full testimonial management platform:

Collect: Shareable collection pages (text + video, no sign-up needed for customers)
Analyze: AI-powered sentiment analysis, theme detection, and highlight suggestions using Claude Haiku
Display: 5 widget layouts — Wall, Carousel, Badge, Popup, Marquee
Track: Conversion tracking to see which testimonials actually drive sign-ups

The embed widget uses Shadow DOM for zero CSS conflicts and loads in under 10ms from CDN.

Tech Stack

Next.js + React
Drizzle ORM + Neon PostgreSQL (serverless)
Clerk Auth (GitHub + Google + Email)
Claude Haiku API for AI analysis
Shadow DOM embed widget (3.1KB gzipped)
Vercel deployment

Try It

Trustfolio is live with a generous free tier — 15 testimonials, 1 widget, full AI analysis. No credit card required.

Check it out: trustfolio.dev

I'd love to hear your feedback!

Regex Lookahead and Lookbehind: Patterns Every Developer Should Know

Ahnhyeongkyu — Wed, 04 Mar 2026 02:40:11 +0000

Lookaheads and lookbehinds are the regex features that separate "I know regex" from "I know regex." They let you match patterns based on what comes before or after — without including that context in the match itself.

Once you understand them, problems that seemed impossible with basic regex become straightforward. Let's break them down.

What Are Lookaheads and Lookbehinds?

Think of regular expressions as a cursor moving through text. Normally, every part of your pattern consumes characters — the cursor advances as it matches. Lookaheads and lookbehinds are different: they peek at surrounding text without consuming it. The cursor looks, but doesn't move.

An analogy: Imagine you're searching a bookshelf for books with red covers. A normal regex is like pulling each book off the shelf to check it. A lookahead is like glancing at the next book without pulling it out. A lookbehind is like glancing at the previous book. You're gathering information, but you're not removing anything from the shelf.

This "zero-width" property is what makes them powerful. You can assert that certain text exists nearby without including it in your match result.

The Four Types: A Syntax Reference

Type	Syntax	Meaning
Positive Lookahead	`(?=...)`	What follows must match
Negative Lookahead	`(?!...)`	What follows must not match
Positive Lookbehind	`(?<=...)`	What precedes must match
Negative Lookbehind	`(?<!...)`	What precedes must not match

The key to remembering the syntax:

= means positive (it does match)
! means negative (it doesn't match)
< means look behind (to the left)
No < means look ahead (to the right)

Now let's put them to work with five real-world examples.

Example 1: Password Validation

The problem: Validate that a password contains at least one uppercase letter, one lowercase letter, one digit, and is at least 8 characters long.

Without lookaheads, you'd need to check each condition separately or write an absurdly complex alternation. With lookaheads, you can stack multiple conditions at the same position:

const passwordRegex = /^(?=.*[A-Z])(?=.*[a-z])(?=.*\d).{8,}$/;

// Test cases
passwordRegex.test('MyPass1234');  // true — has upper, lower, digit, 8+ chars
passwordRegex.test('mypass1234');  // false — no uppercase
passwordRegex.test('MYPASS1234');  // false — no lowercase
passwordRegex.test('MyPassword');  // false — no digit
passwordRegex.test('Mp1');         // false — too short

How it works, step by step:

^ — Start of string
(?=.*[A-Z]) — Lookahead: somewhere ahead there's an uppercase letter. The cursor doesn't move.
(?=.*[a-z]) — Lookahead: somewhere ahead there's a lowercase letter. Still at position 0.
(?=.*\d) — Lookahead: somewhere ahead there's a digit. Still at position 0.
.{8,}$ — Now actually consume: match 8 or more of any character to the end.

All three lookaheads fire from the same starting position. They each independently scan the entire string for their condition. Only when all three succeed does the engine proceed to the actual match.

Adding more rules is trivial. Need a special character too?

const strongPassword = /^(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[!@#$%^&*]).{10,}$/;

Example 2: Extract Prices Without Currency Symbols

The problem: You have text containing prices in various formats and you want to extract just the numeric values, without the currency symbol.

const text = 'Products: $49.99, €120.00, £75.50, $1,299.00';

// Positive lookbehind: match numbers preceded by a currency symbol
const priceRegex = /(?<=[$€£])\d[\d,.]*\d/g;

const prices = text.match(priceRegex);
// => ['49.99', '120.00', '75.50', '1,299.00']

How it works:

(?<=[$€£]) — Lookbehind: the position must be preceded by $, €, or £. This symbol is NOT included in the match.
\d[\d,.]*\d — Match digits, possibly with commas and decimal points in between.

The beauty here is that the currency symbols are used to locate the right numbers but aren't captured. Without a lookbehind, you'd need a capture group and an extra extraction step:

// Without lookbehind (less clean)
const fallback = /[$€£](\d[\d,.]*\d)/g;
const matches = [...text.matchAll(fallback)].map(m => m[1]);

The lookbehind version is more direct and readable.

Example 3: Match Words NOT Followed by Specific Text

The problem: In a codebase, find all uses of import that are NOT followed by type (you want value imports, not TypeScript type imports).

const code = \`
import React from 'react';
import type { FC } from 'react';
import { useState } from 'react';
import type { Props } from './types';
import axios from 'axios';
\`;

const valueImports = /import(?!\s+type)\s+.+/g;
const matches = code.match(valueImports);
// => [
//   "import React from 'react';",
//   "import { useState } from 'react';",
//   "import axios from 'axios';"
// ]

How it works:

import — Match the literal text "import"
(?!\s+type) — Negative lookahead: what follows must NOT be whitespace + "type"
\s+.+ — Then consume the rest of the import statement

The negative lookahead acts as a filter. It says "yes, I found import, but only keep it if type doesn't come next."

Another practical use — excluding test files:

// Match .js files that are NOT test files
const regex = /\w+(?!\.test)\.js/g;

'app.js utils.test.js config.js'.match(regex);
// => ['app.js', 'config.js']

Example 4: Parse Structured Log Files

The problem: You're parsing log entries and need to extract the log level, but only from lines that contain an IP address (indicating network-related events).

Sample log:

2026-03-01 10:15:32 [ERROR] Connection timeout from 192.168.1.100
2026-03-01 10:15:33 [INFO] Cache cleared successfully
2026-03-01 10:15:34 [WARN] Rate limit approaching for 10.0.0.55
2026-03-01 10:15:35 [DEBUG] Query executed in 42ms
2026-03-01 10:15:36 [ERROR] SSL handshake failed from 172.16.0.200

const logs = \`2026-03-01 10:15:32 [ERROR] Connection timeout from 192.168.1.100
2026-03-01 10:15:33 [INFO] Cache cleared successfully
2026-03-01 10:15:34 [WARN] Rate limit approaching for 10.0.0.55
2026-03-01 10:15:35 [DEBUG] Query executed in 42ms
2026-03-01 10:15:36 [ERROR] SSL handshake failed from 172.16.0.200\`;

// Positive lookahead: match log level only if an IP address appears later in the line
const networkLogs = /\[(ERROR|WARN|INFO|DEBUG)\](?=.*\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/gm;

const matches = [...logs.matchAll(networkLogs)].map(m => m[1]);
// => ['ERROR', 'WARN', 'ERROR']

How it works:

\[(ERROR|WARN|INFO|DEBUG)\] — Match the log level in brackets, capturing the level name
(?=.*\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) — Lookahead: somewhere on this line, there's an IP address pattern

Lines without IP addresses (the INFO cache line and the DEBUG query line) are excluded. The lookahead lets you filter on content that appears much later in the line without having to match everything in between.

Combining with lookbehind to extract the IP itself:

// Extract IPs that appear after the word "from"
const fromIPs = /(?<=from\s)\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/g;
logs.match(fromIPs);
// => ['192.168.1.100', '172.16.0.200']

Example 5: Email Username Extraction

The problem: Extract the username portion of email addresses (everything before the @) from a block of text.

const text = \`
Contact us:
  - Support: support@codeneat.dev
  - Sales: sales.team@codeneat.dev
  - Bug reports: bugs+tracker@codeneat.dev
\`;

// Positive lookahead: match word characters (plus dots, hyphens, and +)
// that are followed by @
const usernameRegex = /[\w.+-]+(?=@)/g;

const usernames = text.match(usernameRegex);
// => ['support', 'sales.team', 'bugs+tracker']

How it works:

[\w.+-]+ — Match one or more word characters, dots, plus signs, or hyphens
(?=@) — Lookahead: this match must be followed by @, but don't include @ in the result

Without the lookahead, you'd match the @ and then have to strip it:

// Without lookahead
const fallback = /([\w.+-]+)@/g;
const matches = [...text.matchAll(fallback)].map(m => m[1]);

The lookahead version is cleaner because the match itself is exactly what you want.

Extracting the domain instead (using lookbehind):

const domainRegex = /(?<=@)[\w.-]+/g;
text.match(domainRegex);
// => ['codeneat.dev', 'codeneat.dev', 'codeneat.dev']

Browser and Engine Support

Lookaheads have been supported everywhere for decades. Lookbehinds are newer — here's the current status:

Feature	Chrome	Firefox	Safari	Node.js	Edge
Positive Lookahead `(?=...)`	All versions	All versions	All versions	All versions	All versions
Negative Lookahead `(?!...)`	All versions	All versions	All versions	All versions	All versions
Positive Lookbehind `(?<=...)`	62+	78+	16.4+	8.10+	79+
Negative Lookbehind `(?<!...)`	62+	78+	16.4+	8.10+	79+

Key takeaway: As of 2026, lookbehinds are safe to use in all modern browsers. The only concern is if you need to support Safari 16.3 or older (released early 2023). For server-side JavaScript (Node.js), lookbehinds have been available since Node 8.

If you need to support older environments, you can always rewrite lookbehinds using capture groups:

// Lookbehind version (modern)
/(?<=\$)\d+/g

// Capture group equivalent (universal)
/\$(\d+)/g  // then use match[1]

Common Pitfalls

1. Variable-length lookbehinds: JavaScript supports variable-length lookbehinds, but some regex engines (notably older Python re module) don't. If your pattern works in JS but fails elsewhere, this might be why.

2. Performance with .* in lookaheads: Patterns like (?=.*something) cause the engine to scan the entire remaining string. In tight loops or very long strings, stack multiple specific lookaheads rather than using greedy quantifiers.

3. Forgetting that lookarounds are zero-width: A common mistake is expecting (?=foo)bar to match "foobar". It won't — after the lookahead asserts "foo" is ahead, the cursor is still at the same position, and it tries to match "bar" starting where "foo" starts. You'd want (?=foo)foobar or just foobar.

Test Your Patterns Live

Regex is a skill you build by doing. Reading about lookaheads is useful; writing and testing them is where the understanding clicks.

Test these patterns live at codeneat.dev/regex-tester — it provides real-time match highlighting, capture group visualization, and runs entirely in your browser so your test data stays private.

Paste any of the examples from this article and experiment. Change the patterns, try different inputs, and build intuition for how lookaheads and lookbehinds actually work.

The Complete Guide to JSON Syntax Errors (With Examples and Fixes)

Ahnhyeongkyu — Wed, 04 Mar 2026 02:35:24 +0000

If you've ever stared at Unexpected token ... in JSON at position ... and had no idea what went wrong, this guide is for you.

JSON looks simple — and it is. But its strictness catches developers off guard constantly. Unlike JavaScript objects, JSON has zero tolerance for syntax shortcuts. One wrong character and the entire document fails to parse.

Here are the 7 most common JSON syntax errors, why they happen, and how to fix each one.

Error 1: Trailing Commas

The single most common JSON error. You'll hit this one more than all others combined.

Broken:

{
  "name": "Alice",
  "age": 30,
  "role": "developer",
}

The error:

SyntaxError: Unexpected token } in JSON at position 56

Why it happens: JavaScript objects and arrays happily accept trailing commas. JSON does not. When you copy an object literal from your code into a .json file or an API request body, that trailing comma comes along for the ride.

Fixed:

{
  "name": "Alice",
  "age": 30,
  "role": "developer"
}

JavaScript detection and fix:

// Quick fix: strip trailing commas before parsing
function removeTrailingCommas(jsonString) {
  return jsonString.replace(/,\s*([\]}])/g, '$1');
}

const cleaned = removeTrailingCommas('{"a": 1, "b": 2,}');
const parsed = JSON.parse(cleaned);

Arrays have the same issue:

// BROKEN
["red", "green", "blue",]

// FIXED
["red", "green", "blue"]

Error 2: Single Quotes Instead of Double Quotes

Broken:

{
  'name': 'Alice',
  'active': true
}

The error:

SyntaxError: Unexpected token ' in JSON at position 4

Why it happens: JavaScript allows single quotes, backticks, and double quotes for strings. JSON only allows double quotes. Period. This is defined in RFC 8259 and there are no exceptions.

Fixed:

{
  "name": "Alice",
  "active": true
}

JavaScript detection and fix:

// Replace single-quoted keys and values with double quotes
// WARNING: This is a naive approach — use a proper parser for production
function singleToDoubleQuotes(str) {
  return str.replace(/'/g, '"');
}

// Better approach: use JSON5 for lenient parsing
// npm install json5
const JSON5 = require('json5');
const parsed = JSON5.parse("{'name': 'Alice'}");
// => { name: "Alice" }

Error 3: Unquoted Keys

Broken:

{
  name: "Alice",
  age: 30
}

The error:

SyntaxError: Unexpected token n in JSON at position 4

Why it happens: JavaScript object literals allow unquoted keys when the key is a valid identifier. JSON requires every key to be a double-quoted string — no exceptions, even for simple alphanumeric keys.

Fixed:

{
  "name": "Alice",
  "age": 30
}

JavaScript tip: If you're generating JSON from code, always use JSON.stringify() rather than constructing strings manually. It handles quoting automatically:

const obj = { name: "Alice", age: 30 };
const json = JSON.stringify(obj, null, 2);
// Produces valid JSON with double-quoted keys every time

Error 4: Comments in JSON

Broken:

{
  // Database settings
  "host": "localhost",
  "port": 5432, /* default PostgreSQL port */
  "database": "myapp"
}

The error:

SyntaxError: Unexpected token / in JSON at position 4

Why it happens: Standard JSON (RFC 8259) has no comment syntax at all. No //, no /* */, no #. This is an intentional design choice by Douglas Crockford — JSON is a data format, not a configuration language.

Fixed (option A — remove comments):

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Fixed (option B — use a format that supports comments):

If you genuinely need comments in your config files, consider these alternatives:

JSONC (JSON with Comments) — used by VS Code's settings.json, TypeScript's tsconfig.json
JSON5 — superset of JSON that supports comments, trailing commas, and more
YAML — full comment support with #

JavaScript strip-and-parse:

// Strip single-line and multi-line comments from a JSON string
function stripJsonComments(str) {
  return str
    .replace(/\/\/.*$/gm, '')        // Remove // comments
    .replace(/\/\*[\s\S]*?\*\//g, '') // Remove /* */ comments
    .replace(/,\s*([\]}])/g, '$1');   // Clean up any resulting trailing commas
}

const raw = \`{
  // server config
  "host": "localhost",
  "port": 5432
}\`;

const parsed = JSON.parse(stripJsonComments(raw));

Error 5: undefined, NaN, and Infinity

Broken:

{
  "name": "Alice",
  "middleName": undefined,
  "score": NaN,
  "limit": Infinity
}

The error:

SyntaxError: Unexpected token u in JSON at position 32

Why it happens: undefined, NaN, Infinity, and -Infinity are JavaScript-specific values. They have no representation in JSON. The only valid JSON values are: strings, numbers (finite), booleans (true/false), null, objects, and arrays.

Fixed:

{
  "name": "Alice",
  "middleName": null,
  "score": null,
  "limit": null
}

JavaScript handling with JSON.stringify replacer:

const data = {
  name: "Alice",
  middleName: undefined,
  score: NaN,
  limit: Infinity
};

// Default behavior: undefined properties are SILENTLY DROPPED
JSON.stringify(data);
// => '{"name":"Alice","score":null,"limit":null}'
// Note: middleName is gone entirely, NaN and Infinity become null

// Custom replacer for explicit control:
const safe = JSON.stringify(data, (key, value) => {
  if (value === undefined) return null;
  if (typeof value === 'number' && !isFinite(value)) return null;
  return value;
}, 2);

Watch out: JSON.stringify() silently drops undefined properties rather than converting them to null. This catches people off guard when they expect round-trip consistency.

Error 6: BOM (Byte Order Mark) Characters

Broken (invisible!):

The JSON looks perfectly valid in your editor:

{"name": "Alice", "age": 30}

But parsing fails with:

SyntaxError: Unexpected token  in JSON at position 0

Why it happens: Some text editors (notably older versions of Notepad on Windows, and some Excel CSV exports) prepend an invisible UTF-8 BOM character (\uFEFF) to files. It's invisible in most editors but causes JSON.parse() to choke because the first character isn't { or [ — it's a zero-width no-break space.

How to detect it:

const raw = fs.readFileSync('data.json', 'utf8');
console.log(raw.charCodeAt(0)); // 65279 = BOM is present
console.log(raw[0] === '\uFEFF'); // true

JavaScript fix:

function stripBOM(str) {
  return str.charCodeAt(0) === 0xFEFF ? str.slice(1) : str;
}

const raw = fs.readFileSync('data.json', 'utf8');
const parsed = JSON.parse(stripBOM(raw));

Prevention: Configure your editor to save files without BOM. In VS Code, check the encoding indicator in the bottom status bar — it should say "UTF-8", not "UTF-8 with BOM".

Error 7: Missing or Mismatched Brackets

Broken:

{
  "users": [
    {"name": "Alice", "age": 30},
    {"name": "Bob", "age": 25}
}

The error:

SyntaxError: Unexpected token } in JSON at position 79

Why it happens: The users array was opened with [ but never closed with ]. In deeply nested JSON documents — especially those with hundreds of lines — it's easy to lose track of bracket pairs. A single missing bracket or brace invalidates the entire document.

Fixed:

{
  "users": [
    {"name": "Alice", "age": 30},
    {"name": "Bob", "age": 25}
  ]
}

How to find the problem:

The error position (at position 79) tells you where the parser gave up, but the actual mistake is usually earlier in the document. Here's a systematic approach:

function findBracketMismatch(jsonString) {
  const stack = [];
  const pairs = { '{': '}', '[': ']' };

  for (let i = 0; i < jsonString.length; i++) {
    const char = jsonString[i];
    if (char === '{' || char === '[') {
      stack.push({ char, position: i });
    } else if (char === '}' || char === ']') {
      const last = stack.pop();
      if (!last) {
        console.log(\`Extra closing '${char}' at position ${i}\`);
        return;
      }
      if (pairs[last.char] !== char) {
        console.log(\`Mismatch: '${last.char}' at ${last.position} closed by '${char}' at ${i}\`);
        return;
      }
    }
  }

  if (stack.length > 0) {
    const unclosed = stack.pop();
    console.log(\`Unclosed '${unclosed.char}' at position ${unclosed.position}\`);
  }
}

A Defensive Parsing Pattern

In production code, you should never call JSON.parse() without error handling. Here's a robust pattern:

function safeJsonParse(raw) {
  // Step 1: Strip BOM if present
  const cleaned = raw.charCodeAt(0) === 0xFEFF ? raw.slice(1) : raw;

  // Step 2: Attempt parse
  try {
    return { data: JSON.parse(cleaned), error: null };
  } catch (err) {
    return {
      data: null,
      error: {
        message: err.message,
        // Extract position from error message
        position: parseInt(err.message.match(/position (\d+)/)?.[1] ?? '-1', 10),
      },
    };
  }
}

// Usage
const result = safeJsonParse(userInput);
if (result.error) {
  console.error(\`Parse error at position ${result.error.position}: ${result.error.message}\`);
} else {
  console.log(result.data);
}

Quick Reference: JSON vs JavaScript Objects

Feature	JavaScript Object	JSON
Trailing commas	Allowed	Not allowed
Single quotes	Allowed	Not allowed
Unquoted keys	Allowed (identifiers)	Not allowed
Comments	Allowed	Not allowed
`undefined`	Allowed	Not allowed
`NaN` / `Infinity`	Allowed	Not allowed
Functions as values	Allowed	Not allowed
Key order	Preserved (mostly)	Preserved (mostly)

Stop Guessing, Start Validating

The fastest way to debug JSON issues is to use a proper validator that pinpoints the exact error location and suggests fixes.

Validate your JSON instantly at codeneat.dev/json-formatter — it highlights syntax errors inline, shows the exact position of the problem, and runs entirely in your browser so your data stays private.

Why Your Online Dev Tools Might Be Leaking Your Code (And What to Do About It)

Ahnhyeongkyu — Wed, 04 Mar 2026 02:27:41 +0000

The Problem Nobody Talks About

Picture this: you're debugging an API response at 11 PM. The JSON blob is a mess — deeply nested, minified, impossible to read. You do what every developer does: copy, open your favorite online formatter, paste, done.

But here's the thing. That JSON blob contained an API key. A user's email address. Maybe a session token. And the tool you just pasted it into? It sent every byte to a remote server.

This isn't a hypothetical scenario. It happens millions of times a day across the developer community. We've trained ourselves to be paranoid about hardcoding secrets, we rotate keys religiously, we use environment variables — and then we paste production data into a random website's text area without blinking.

How Bad Is It, Really?

Let's run a simple experiment. Open any popular online JSON formatter. Now open your browser's DevTools, switch to the Network tab, and paste some JSON.

Watch what happens.

On many tools, you'll see an outbound POST request the moment you click "Format." Your data just traveled to someone else's server. Depending on the tool's privacy practices, that data might be:

Logged for debugging or analytics purposes
Cached on their CDN or application server
Processed server-side with no guaranteed deletion
Stored in backups that persist for months

Now multiply this across every tool in your workflow. JWT decoders, Base64 converters, regex testers, SQL formatters. Every paste is a potential data leak.

What's Actually at Risk?

Think about what developers routinely paste into online tools:

JWT tokens — contain user IDs, roles, permissions, email addresses, and expiration data.
API responses — often include PII (names, emails, phone numbers), internal IDs, and business logic details.
Configuration files — database connection strings, API keys, service credentials.
SQL queries — table names, column structures, business logic encoded in WHERE clauses.
Hash inputs — passwords being tested, secret keys being verified.

A single paste can expose more about your infrastructure than a careless README ever could.

The Fix: Client-Side-Only Processing

The solution is straightforward: use tools that never send your data anywhere. Client-side-only tools run all processing logic in your browser using JavaScript. The data you paste stays in your browser tab and is never transmitted over the network.

This isn't a marketing claim you have to take on faith — it's something you can verify yourself in 10 seconds with your browser's Network tab.

CodeNeat is a collection of developer tools built on exactly this principle. Every tool runs 100% in the browser. No server calls, no analytics on your input data, no exceptions.

Let me walk you through three tools and show you what privacy-first development tooling looks like in practice.

Tool 1: JSON Formatter — The One You Use Most

JSON formatting is probably the most common task in any developer's day. CodeNeat's JSON Formatter handles it entirely in the browser.

It instantly formats with proper indentation, syntax highlighting, and a collapsible tree view. You can switch between 2-space and 4-space indentation, minify it back, or explore nested structures using the tree viewer.

The privacy angle: Open the Network tab — you'll see zero outbound requests related to your data.

The tool also supports JSON Path queries, so you can extract specific data without ever sending the full document anywhere.

Tool 2: JWT Decoder — Where Privacy Matters Most

JWTs are arguably the most sensitive data developers routinely paste into online tools. A typical JWT payload contains user IDs, permission models, organizational structure — all encoded in a token.

CodeNeat's JWT Decoder splits the token into its three parts (header, payload, signature), decodes each one, and displays the result with syntax highlighting. It flags expired tokens and shows human-readable timestamps.

Everything happens in your browser. The JWT never leaves your machine.

Tool 3: Hash Generator — Verify Without Exposing

CodeNeat's Hash Generator supports MD5, SHA-1, SHA-256, and SHA-512. Type or paste your input, and the hashes are computed instantly in the browser using the Web Crypto API.

No server ever sees your input. The hash computation runs in a Web Worker to keep the UI responsive, even for large inputs.

How to Verify Any Tool's Privacy Claims

Don't take anyone's word for it — including mine. Here's a 30-second verification process:

Open DevTools (F12 or Cmd+Option+I)
Go to the Network tab
Check "Preserve log"
Paste your data into the tool and trigger processing
Inspect every request — check the Payload/Request Body tab

If you see your input data in an outbound request, that tool is server-side. If the only requests are for static assets, the tool is genuinely client-side.

Beyond Individual Tools: Building Privacy Into Your Workflow

Privacy-first tooling isn't just about individual tools. It's a mindset:

Audit your bookmarks. How many of your saved dev tools are server-side?
Check before you paste. If the data contains anything sensitive, verify the tool's processing model first.
Educate your team. Share this Network-tab verification technique in your next team standup.
Consider compliance. If you handle GDPR-covered data or HIPAA records, pasting it into server-side tools may be a compliance violation.

Wrapping Up

We lock down our repos, rotate our keys, encrypt our databases, and audit our dependencies. But we paste sensitive data into random websites every single day.

It's time to close that gap. Client-side tools aren't a compromise — they're faster (no network round-trip), work offline, and provably protect your data.

Try it yourself at codeneat.dev — and open your Network tab to verify.

I Built a Free Statistics Calculator with Next.js — Here's What I Learned

Ahnhyeongkyu — Mon, 23 Feb 2026 10:24:56 +0000

As a developer who also does research, I got tired of switching between SPSS, R, and Excel just to run basic statistical tests. So I built StatMate — a free, browser-based statistics calculator that handles 20 different tests and outputs APA-formatted results.

Here's the story of how I built it and what I learned along the way.

The Problem

Every semester, thousands of students and researchers face the same struggle:

SPSS costs $100+/month
R has a steep learning curve
Excel can't format APA tables automatically
Online calculators only handle one test at a time

I wanted to build something that just works — paste your data, pick a test, get properly formatted results.

The Stack

Next.js 16 with Turbopack for fast builds
TypeScript for type-safe statistics calculations
Tailwind CSS v4 for styling
next-intl for trilingual support (English, Korean, Japanese)
All statistics computed client-side in the browser — no data leaves your machine

What It Does

StatMate currently supports 20 statistical tests:

Parametric: t-tests (independent, paired, one-sample), ANOVA (one-way, two-way, repeated measures), simple & multiple regression, logistic regression
Non-parametric: Mann-Whitney U, Wilcoxon, Kruskal-Wallis, Friedman
Other: Chi-square, Fisher's exact, McNemar, correlation, descriptive stats, sample size/power, Cronbach's alpha, factor analysis (EFA)

Every test includes:

APA 7th edition formatted results — copy-paste ready
Assumption checks (normality, homogeneity of variance)
Interactive charts (box plots, scatter plots, residual plots)
PDF export (free) and Word/DOCX export (Pro)
Example data so users can try before entering their own

Technical Challenges

1. Implementing Statistics from Scratch

No external stats library — I wrote all 20 statistical modules in TypeScript. The trickiest parts:

Matrix operations for factor analysis (eigenvalue decomposition, varimax rotation)
Probability distributions (t, F, chi-square) using series approximations
Post-hoc tests (Bonferroni, Tukey HSD, Dunn's test)

I validated every calculator against R 4.3 to ensure accuracy.

2. APA Formatting

APA 7th edition has very specific formatting rules. Each test has its own reporting format:

t(58) = 2.45, p = .017, d = 0.63
F(2, 87) = 4.12, p = .019, partial eta-squared = .086

Building a system that automatically generates these strings with correct rounding, italics handling, and effect size interpretation was more work than expected.

3. i18n for Statistics

Translating a statistics app into 3 languages isn't just about UI text. Statistical terminology, APA conventions, and number formatting all vary by locale. next-intl handled most of it, but edge cases required custom logic.

What I Learned

Client-side computation is underrated. Users trust a tool more when their data never leaves the browser.
APA formatting is a product feature, not a nice-to-have. It's the #1 thing users mention.
Trilingual from day one opened up markets I wouldn't have reached otherwise.
Free tools need a Pro tier to be sustainable. Ours includes AI-powered result interpretation and DOCX export.

Try It Out

StatMate is live at statmate.org. Everything is free — 20 calculators, PDF export, assumption checks, and charts.

If you're building tools for researchers or students, I'd love to hear about your experience. Drop a comment or check out the project!

Have questions about implementing statistics in JavaScript, APA formatting, or building multilingual Next.js apps? Happy to discuss in the comments.