DEV Community: zhihu wu

3 Times You Need Base64 (and One Time You Definitely Don't)

zhihu wu — Wed, 01 Jul 2026 01:40:20 +0000

When Base64 Makes Sense

Base64 converts binary data into text using 64 printable ASCII characters so it can travel through systems that don't handle raw bytes well. Here are three times you actually need it, and one time you shouldn't bother.

1. Embedding Small Images in HTML/CSS

Inline images via data URIs eliminate HTTP requests. For tiny assets like icons and email signature graphics, this is genuinely faster than a separate file:

<img src="data:image/png;base64,iVBORw0KGgo..." alt="logo">

The tradeoff: Base64 inflates file size by ~33%. For anything over 5KB, a separate file with browser caching wins. But for that one-off SVG favicon or email footer, inline Base64 is perfect.

2. Sending Binary in JSON APIs

JSON can't carry raw bytes. When your API needs file uploads alongside metadata, Base64-encoding is the standard approach:

{
  "filename": "report.pdf",
  "content": "JVBERi0xLjQKJeLjz9MK...",
  "userId": 422
}

Most cloud APIs (AWS Lambda payloads, webhook implementations) use this pattern under the hood.

3. Debugging Tokens and Auth Headers

JWT payloads are just Base64URL. Basic Auth headers are Base64-encoded user:pass. When debugging, paste a JWT's middle segment into any Base64 decoder and read the claims directly. Same trick for Authorization: Basic *** headers — decode the token after "Basic " to see the credentials.

When NOT to Use Base64

For security. Base64 is encoding, not encryption. It's trivially reversible and offers zero protection. I've seen devs Base64-encode API keys in client-side code thinking it hides them. It doesn't. Use AES-256 for actual security.

Need a quick Base64 encoder/decoder? I use this free tool — it runs entirely in the browser, handles files and data URIs, and works with both standard and URL-safe variants.

Your JSON Is Valid... Until It's Not: Common Parse Errors and How to Fix Them

zhihu wu — Wed, 24 Jun 2026 13:02:56 +0000

We've all seen it: an API response that looks perfectly fine, but JSON.parse() throws a cryptic error at position 0. Or position 472. Or somewhere deep inside a 10,000-line config file. Here are the most common JSON syntax issues and how to diagnose them fast.

1. Trailing Commas (The #1 Offender)

{
  "name": "App",
  "version": "2.0.1",
  "dependencies": [
    "react",
    "lodash",
  ],
}

JSON spec (RFC 8259) does not allow trailing commas. JavaScript and TypeScript are forgiving, so your IDE doesn't complain — but strict JSON parsers will fail. The fix: remove the comma after the last array item and last object key.

2. Smart Quotes vs. Straight Quotes

If you copy JSON from a word processor or a ChatGPT output, you might get "smart quotes" (curly) instead of straight quotes. They look similar but are different Unicode characters:

// This WILL fail — smart quotes on the key
{“name”: “hello”}

// This is correct
{"name": "hello"}

3. Unquoted Keys

JavaScript objects let you use unquoted keys. JSON does not:

// Valid JS object, INVALID JSON
{name: "Alice", age: 30}

// Correct JSON
{"name": "Alice", "age": 30}

4. The Invisible BOM

If your JSON file starts with a UTF-8 BOM (Byte Order Mark), many parsers fail at position 0 — even though the file looks empty of problems. cat file.json | xxd | head -1 and look for EF BB BF at the start.

5. Single Quotes

JavaScript accepts both single and double quotes for strings. JSON does not:

// Invalid
{'key': 'value'}

// Valid
{"key": "value"}

Debugging Tip

When you encounter a parse error, don't just stare at the JSON. Use a formatter that shows the exact line and column of the first syntax error.

I built a free JSON formatter and validator for exactly this purpose — paste your JSON, click Validate, and it tells you exactly where the error is. All processing happens in your browser, no data leaves your machine.

The most useful feature: it works offline once the page loads. I've used it on flights to debug local config files without internet.

Got a favorite JSON debugging technique? Drop it in the comments.

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

zhihu wu — Sun, 21 Jun 2026 13:05:23 +0000

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

Every developer has done it: you Google "regex for email," copy the first Stack Overflow answer, paste it into your code, and cross your fingers that it covers all edge cases. Then six months later, user+tag@domain.co.uk slips through and breaks something.

Let's fix that. Here are five regex patterns you probably copy-paste, explained so you actually understand them — and can adapt them yourself.

1. Email Validation: The Pattern Everyone Gets Wrong

[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}

Broken down:

[a-zA-Z0-9._%+-]+ — username part: letters, digits, dots, underscores, percent, plus, hyphens. The + means "one or more."
@ — literal at sign.
[a-zA-Z0-9.-]+ — domain name: letters, digits, dots, hyphens.
\. — literal dot (escaped because . normally means "any character").
[a-zA-Z]{2,} — TLD: at least 2 letters.

When it fails: Unicode characters in the local part (café@example.com), quoted strings, IP-address domains. For production email validation, send a confirmation link — regex alone can't guarantee deliverability.

2. URL Extraction: Greedy vs. Lazy Trap

https?:\/\/[^\s/$.?#].[^\s]*

https? — "http" optionally followed by "s." The ? makes the preceding character optional.
:\/\/ — literal :// (forward slashes must be escaped outside character classes).
[^\s/$.?#] — match one character that is NOT whitespace, /, $, ., ?, or #. This prevents matching bare punctuation.
[^\s]* — then match everything until whitespace (\s). Note the * (zero or more) — if the URL is followed by a space, it stops there.

Pitfall: The * after [^\s] is greedy — always use it with a character class ([^\s]) rather than . to avoid gobbling up surrounding text. Test this in the regex tester with URLs embedded in paragraphs to see the difference.

3. IP Address Extraction: Backreference Magic

\b(?:\d{1,3}\.){3}\d{1,3}\b

\b — word boundary: ensures we don't match "192.168.1.1" inside "192.168.1.100".
(?:\d{1,3}\.) — a non-capturing group (?:): one to three digits followed by a dot. Non-capturing groups group without saving the match.
{3} — repeat the group exactly 3 times. So we get 123.45.67.
\d{1,3} — final octet, no trailing dot.
\b — word boundary again.

This pattern doesn't validate IPs — it matches 999.999.999.999. For validation, you'd need a much more complex pattern checking each octet's range (0-255). This pattern's job is extraction, not validation — it finds anything that looks like an IP in a log file.

4. Date Extraction (ISO 8601): Character Classes Done Right

\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])

\d{4} — exactly 4 digits (the year).
- — literal hyphen.
(0[1-9]|1[0-2]) — month: either 0 followed by 1-9 (Jan-Sep) OR 1 followed by 0-2 (Oct-Dec). The | means "OR."
- — literal hyphen.
(0[1-9]|[12]\d|3[01]) — day: 0[1-9] (1st-9th) OR [12]\d (10-29) OR 3[01] (30-31).

Known limitation: This accepts invalid dates like 2025-02-30. For bulletproof date validation, parse with a date library after the regex confirms the format.

5. The "Everything Between Tags" Problem

<([a-zA-Z][a-zA-Z0-9]*)>(.*?)<\/\1>

<([a-zA-Z][a-zA-Z0-9]*)> — opening tag: <, a letter, then optional alphanumeric characters, >. The parentheses capture the tag name.
(.*?) — content between tags. The ? after * makes it lazy — stop at the first closing tag, not the last.
<\/\1> — closing tag: <, /, then (backreference to the first capture group, the tag name), >.

Without the lazy *?, <.*> applied to <div>hello</div> would match the entire string instead of just <div>. This is the #1 "why isn't my regex working" moment.

The Debugging Workflow I Actually Use

Start with a known-good preset (email, URL, IPv4 from the tool's library)
Tweak one thing at a time, watching the match highlights change in real-time
Add edge cases to the test string: empty input, special chars, unicode
Only move to production code when the tester shows exactly what you expect

I use the free Regex Tester at codetoolbox.pro/tools/regex-tester.html for this — it runs entirely in the browser, highlights matches instantly, and shows capture groups individually. No signup, no server uploads.

What's the regex that burned you the worst? Drop a comment — genuinely curious how many of us have been bitten by the same patterns.

Why Your API Calls Break: A Developer's Guide to URL Encoding

zhihu wu — Fri, 19 Jun 2026 13:09:27 +0000

Why Your API Calls Break: A Developer's Guide to URL Encoding

URL encoding is one of those things that seems trivial until it isn't. You fire off an API call, the server returns a 400, and you stare at the URL wondering what went wrong. Nine times out of ten, the answer is encoding.

Here are the three URL encoding mistakes that cost developers hours of debugging — and how to fix them in 30 seconds.

1. The Double-Encoding Trap

This is the most insidious bug. You encode a URL once, pass it through a framework or middleware that encodes it again, and suddenly hello%20world becomes hello%2520world (the % got encoded to %25).

The symptom: Downstream services receive garbled data. OAuth callback URLs fail silently. API gateways forward corrupted parameters.

The fix: Before encoding, decode first to establish a clean baseline:

// Bad: might double-encode
const url = "https://api.example.com?q=" + encodeURIComponent(input);

// Good: decode first if input might already be encoded
const clean = decodeURIComponent(input); // throws if malformed
const url = "https://api.example.com?q=" + encodeURIComponent(clean);

If you suspect double-encoding, look for %25 in your output — that's the smoking gun (% encoded as %25).

2. The `+` vs `%20` Confusion

Both represent a space, but they're NOT interchangeable across contexts.

Context	Encoding	Works?
Query string (form data)	`+`	✅
Query string (manual)	`%20`	✅
Path segment	`+`	❌ Broken
Fragment identifier	`+`	❌ Broken
Everywhere	`%20`	✅ Always

The fix: Use %20 when you're not sure. It works universally. Use + only for application/x-www-form-urlencoded form submissions.

JavaScript's encodeURIComponent() outputs %20 — the safe choice. Python's urllib.parse.quote() does the same by default.

3. Encoding the Wrong Thing

The most common pattern I see in code reviews:

// Wrong: encodeURI on a full URL
const url = encodeURI("https://api.example.com/search?q=hello world");
// Result: "https://api.example.com/search?q=hello%20world" (works, but fragile)

// Wrong: encodeURIComponent on a full URL
const url = encodeURIComponent("https://api.example.com/search?q=hello world");
// Result: "https%3A%2F%2Fapi.example.com%2Fsearch%3Fq%3Dhello%20world" (broken)

The rule: encodeURI() for entire URLs (preserves ://, ?, &, #). encodeURIComponent() for individual parameter values. Never mix them up.

Quick Debugging Workflow

When an API call fails with encoding issues, I use this 3-step process:

Decode the URL to see what's actually there — strip away the percent-encoding and read the raw string
Re-encode a clean version — start fresh from the decoded text
Compare — if the re-encoded version works but the original doesn't, you had double-encoding or mixed encoding

I keep a free URL Encoder/Decoder bookmarked for exactly this: paste a broken URL, hit Decode, and instantly see what went wrong. No signup, no server uploads — everything runs in your browser.

🔗 Try it: codetoolbox.pro/tools/url-encoder.html

Modern Alternative: URLSearchParams

If you're writing modern JavaScript, the URL and URLSearchParams APIs handle encoding automatically:

const params = new URLSearchParams({ q: "hello world", page: "1" });
const url = "https://api.example.com/search?" + params.toString();
// "https://api.example.com/search?q=hello+world&page=1"

This is cleaner, safer, and immune to double-encoding. Use it for new code.

What URL encoding bugs have burned you in production? Drop a comment — I'm collecting war stories.

Your Website Images Are Killing Your SEO — Here's How to Fix It

zhihu wu — Tue, 16 Jun 2026 13:08:02 +0000

The Hidden Speed Killer on Every Website

If your web pages take more than 2.5 seconds to load, Google's Core Web Vitals are already penalizing your rankings. And here's the uncomfortable truth: unoptimized images are almost always the single biggest culprit.

A typical web page downloads 1.5–3 MB of data on desktop — and images account for 50–80% of those bytes. A single uncompressed hero image at 4000×3000px can weigh 5 MB. Multiply that by a gallery of 10 product photos and you've got 50 MB of images dragging down every visitor's experience.

The Fix Is Simpler Than You Think

Compressing images before upload can shrink them by 60–85% with zero visible quality loss. Here's what actually works:

1. Choose the right format

JPEG for photographs — lossy but tiny
PNG for screenshots, logos, and anything needing transparency — lossless but larger
WebP for the best of both worlds — typically 25–34% smaller than JPEG at identical quality, supported everywhere now

2. Use the quality sweet spot
70–80% is the magic range for web images. Your visitors won't notice the difference on a screen, but your page will load dramatically faster. Reserve 85%+ for photography portfolios; use 60% for thumbnails.

3. Compress locally, not on some server
Most "free" online compressors upload your images to remote servers — where they may be stored, analyzed, or resold. Instead, use a browser-based tool that runs entirely on your device using the Canvas API. Nothing transmitted, nothing stored.

A Tool That Actually Respects Your Privacy

I've been using this free image compressor that processes everything locally in the browser — no uploads, no server, no sign-up. It handles JPEG, PNG, and WebP with a side-by-side preview so you can dial in the quality/compression balance before downloading.

For a typical 2 MB product photo, I get it down to ~200 KB at WebP/75% quality — that's a 90% reduction with no visible difference on screen.

The Bottom Line

Image optimization isn't optional anymore — it directly impacts your SEO rankings, bounce rates, and conversion metrics. The good news is that fixing it takes about 30 seconds per image with the right tool. Your users (and Google) will thank you.

What's your go-to image compression workflow? Drop it in the comments.

3 Base64 Tricks Every Developer Should Know

zhihu wu — Sun, 14 Jun 2026 13:02:56 +0000

1. Decode JWT Payloads Without a Library

JSON Web Tokens are everywhere in modern APIs, and their payload is just Base64URL-encoded JSON. When debugging auth issues, you don't need to fire up jwt.io — just grab the middle segment (between the two dots), swap - and _ for + and /, and decode it.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.abc123

That middle part (eyJzdWIiOiIxMjM0NTY3ODkwIn0) decodes to {"sub":"1234567890"} — your user ID, expiry, and scopes, all in plain text. No library required.

2. Peek Inside HTTP Basic Auth Headers

Ever wondered what credentials your HTTP client is actually sending? The Authorization: Basic dXNlcjpwYXNz header is just Base64(username:password). Copy the token after "Basic " and decode it — you'll instantly see if the right credentials are being transmitted. Super useful when debugging misbehaving API clients or checking whether environment variables are being picked up correctly.

3. Embed Images Without Extra HTTP Requests

For small icons, logos, or email signatures, encoding to a data:image/png;base64,... URI lets you embed the image directly in HTML or CSS. No extra HTTP request, no separate file — perfect for single-page demos, HTML email templates, and performance-critical above-the-fold content. Just keep source images under 5KB or the encoded string gets unwieldy.

These tricks come up often enough that I built a quick Base64 encoder/decoder that handles both standard Base64 and Base64URL, works with files up to 50MB, and processes everything locally in your browser — nothing ever hits a server. No signup, no ads.

🔗 Try it at codetoolbox.pro

What Base64 tricks do you use regularly? I'd love to hear about them in the comments.

3 JSON Formatting Tricks That Save Me Hours Every Week

zhihu wu — Thu, 11 Jun 2026 13:08:31 +0000

The Problem

You're debugging an API response, and it looks like this:

{"status":"ok","data":{"items":[{"id":1,"name":"Widget","metadata":{"created":"2024-01-15T08:30:00Z","tags":["electronics","sale"],"pricing":{"usd":29.99,"eur":26.50}},"stock":42},{"id":2,"name":"Gadget","metadata":{"created":"2024-02-20T14:15:00Z","tags":["office"],"pricing":{"usd":15.00,"eur":13.25}},"stock":0}]},"pagination":{"page":1,"total":2}}

Good luck finding the nested pricing field. Now imagine this is 500 lines long.

Here are three tricks that save me hours every week when working with JSON.

1. Pretty-Print First, Debug Later

Before you even look at a JSON blob, format it. Most terminal users reach for python -m json.tool, but that only handles valid JSON. If there's a trailing comma or a missing quote, it fails with an unhelpful error.

A good JSON formatter shows you where the syntax error is, not just that it exists. Missing closing bracket on line 47? An inline formatter catches that instantly.

My workflow: paste raw JSON → identify structural issues → read the formatted output → debug the logic. The formatting step takes 2 seconds but saves 10 minutes of squinting at minified blobs.

2. Collapse Deeply Nested Structures

When an API response goes 4+ levels deep, the tree view is your best friend. Instead of scrolling through 200 lines, collapse everything and expand only the branch you're interested in.

Most dev tools don't do this well, but a dedicated formatter with tree view lets you drill down to response.data.items[3].metadata.pricing.usd in two clicks — without losing context of where you are in the structure.

3. Validate JSON Before It Reaches Production

I've shipped config files with trailing commas more times than I'd like to admit. JSON is stricter than JavaScript — no trailing commas, no single quotes, no comments.

Trailing comma trap: {"key": "value",} works in JS but fails JSON.parse()
Single-quote habit: Switching between JS and JSON makes {'key': 'value'} feel right — it's not
Empty values: {"key": } or {"key": NaN} — JSON doesn't support undefined or NaN

A validator that pinpoints the exact character position of the error catches these before your CI pipeline does.

I use CodeToolbox's JSON Formatter for all three — it handles formatting, tree view, and validation in one page, all client-side (nothing sent to a server).

What's your go-to JSON debugging workflow?

Beyond UUID v4: v7, ULID, and the Future of Unique IDs

zhihu wu — Tue, 09 Jun 2026 13:03:33 +0000

Most developers know UUIDs as those random 36-character strings useful for database keys. But the UUID landscape has evolved significantly — RFC 9562 (May 2024) introduced three new versions. If you're still defaulting to v4 without considering alternatives, you might be leaving performance on the table.

The Classic: UUID v4

UUID v4 generates 122 random bits. It's universally supported, cryptographically random, and requires zero coordination. The downside: random UUIDs fragment B-tree indexes, causing write amplification in high-throughput databases.

-- PostgreSQL: native support since 8.3
CREATE TABLE events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  payload JSONB
);

The Upgrade: UUID v7 (Time-Ordered)

UUID v7 embeds a millisecond-precision Unix timestamp in the first 48 bits, followed by random bits for uniqueness:

|--48 bits timestamp--|--4 ver--|--12 seq--|--62 random--|

Why this matters: time-sortable IDs are index-friendly. Database pages stay compact, writes are sequential, and range queries (WHERE created > X) benefit enormously. In a real benchmark, PostgreSQL INSERT throughput with v7 was 37% higher than v4 under concurrent load.

// uuid v7 (browser-native via crypto.randomUUID in some browsers)
// For broader support, use the uuid npm package
import { v7 } from 'uuid';
const id = v7(); // "018f3a8c-..."

The Compact Alternative: ULID

ULIDs are 26 characters (vs 36 for UUID), use Crockford base32 (URL-safe, no ambiguous characters), and are lexicographically sortable:

01ARZ3NDEKTSV4RRFFQ69G5FAV  // ULID
018f3a8c-1e2d-7f3a-...      // UUID v7
550e8400-e29b-41d4-...      // UUID v4

Decision Framework

Scenario	Use
General purpose, max compatibility	UUID v4
Write-heavy DB, time-based queries	UUID v7
URL-safe, human-readable, compact	ULID
Security-sensitive (no timestamp leak)	UUID v4

Quick Testing

When choosing an ID scheme, I often generate batches to compare formats side by side. There's a free UUID Generator that produces v4 UUIDs in bulk — useful for test fixtures, seed data, or just comparing the visual format against ULIDs. No signup, all browser-side.

The Takeaway

UUID v4 isn't wrong — it's the safe choice. But if you're building a write-heavy service in 2026, spending 5 minutes evaluating v7 or ULID could save you database pain down the road. The time-sortable formats are maturing fast, and most major libraries support them today.

Cron Expressions for CI/CD — Beyond Crontab Basics

zhihu wu — Sat, 06 Jun 2026 13:03:31 +0000

Most developers first encounter cron through crontab -e on a Linux server. But cron syntax now powers schedules far beyond sysadmin scripts — it's the backbone of CI/CD automation.

Cron in the Modern Stack

Three tools you probably use today rely on cron expressions:

GitHub Actions. The schedule trigger uses standard 5-field cron. This runs every weekday at 6 AM UTC:

on:
  schedule:
    - cron: '0 6 * * 1-5'

Kubernetes CronJobs. Same syntax, different YAML:

apiVersion: batch/v1
kind: CronJob
spec:
  schedule: "*/15 * * * *"

AWS EventBridge / CloudWatch. Cloud-native cron for serverless triggers.

The Trick People Miss

When both day-of-month AND day-of-week are specified (not *), cron uses OR logic — the job fires when EITHER matches. This catches everyone:

0 0 1 * 1 doesn't mean "the 1st of the month only if it's Monday." It means "run at midnight on the 1st of every month, AND also every Monday." If you meant the first scenario, set day-of-week to * and add date-checking logic in your script.

Quick Testing Tip

Instead of waiting to see if your cron fires, use a visual generator to confirm the intent. I use CodeToolbox's Cron Expression Generator — pick the fields from dropdowns, read the plain-English description, and check the next 5 execution times before pasting into CI config. All browser-side, no signup needed.

What cron mistake taught you a lesson the hard way?

Loan Math for Developers: 4 Levers That Save Thousands

zhihu wu — Thu, 04 Jun 2026 13:07:29 +0000

If you've ever signed a mortgage, financed a car, or consolidated debt, you've encountered the amortization formula. It looks intimidating:

M = P * [r(1+r)^n] / [(1+r)^n - 1]

But once you understand how each variable moves the needle, you can make decisions that save tens of thousands of dollars. Here's what every developer should know about loan math.

The Formula, Deconstructed

P = principal (what you borrow)
r = monthly interest rate (annual rate / 12)
n = total number of payments (years * 12)
M = your fixed monthly payment

The counterintuitive part: early payments are almost entirely interest. On a $250,000, 30-year mortgage at 6.5%, your first payment sends $1,354 to interest and only $226 to principal. By year 15, the split approaches 50/50. This front-loading is why extra payments early in the term have outsized impact.

The Levers You Can Pull

1. Extra Principal Payments

Adding $100/month to the same mortgage saves ~$49,000 and knocks off 4.5 years. The earlier you start, the larger the compounding effect — because each extra dollar reduces the balance on which ALL future interest is calculated.

2. Biweekly Instead of Monthly

Pay half the monthly amount every two weeks, and you sneak in one extra full payment per year (26 half-payments = 13 full). On a $250k loan, that's ~$53,000 saved and 4-5 years cut from the term — without feeling like you're paying more each month.

3. The 15-Year vs 30-Year Tradeoff

Same $250k loan at 6.5%:

30-year: $1,580/month, $568,861 total — 56% of every dollar is interest
15-year: $2,178/month, $392,069 total — saving $176,791

The monthly jump is real, but the interest savings could buy you a second house.

4. Rate Shopping Actually Matters

A 1% rate difference on a $250k mortgage = over $50,000 in extra interest across 30 years. That single percentage point costs more than most people spend on cars. Always compare APRs (which include fees), not just the advertised rate.

Try It Yourself

I built a Loan Calculator on CodeToolbox that lets you model any of these scenarios in seconds. Enter your numbers, hit Calculate, and you get:

Monthly payment, total interest, and total cost instantly
A visual pie chart showing principal-to-interest ratio
A full amortization table with month-by-month and year-by-year breakdowns

All processing happens in your browser — no signup, no ads, your financial data never leaves your device.

Understanding these four levers (extra payments, biweekly schedule, shorter term, rate shopping) is the difference between paying what the bank asks and paying what you actually need to. The calculator handles the math — you just need to know which knobs to turn.

5 Regex Patterns That Will Save You Hours of Debugging

zhihu wu — Mon, 01 Jun 2026 13:03:24 +0000

If you write code, you've been there — staring at a regex that should work but doesn't. Meanwhile, Stack Overflow suggests nine different patterns, none of which match your actual data.

Here are five regex patterns I reach for constantly. Each one has saved me real debugging time — the kind where you'd otherwise spend 20 minutes on a character that should have been escaped.

1. Extract Key-Value Pairs from Query Strings

/([^?&=]+)=([^&]*)/g

Parse ?page=3&sort=desc&tag=regex into {page: "3", sort: "desc", tag: "regex"} in one line. Way cleaner than split("&") → split("=") loops.

2. Match Paired HTML Tags (Without Crossing Boundaries)

/<(\w+)>[^<]*<\/\\1>/g

The backreference \\1 ensures you match <div>...</div>, not <div>...</span>. This catches unbalanced tags that regex101 won't flag because it only tests one pattern at a time.

3. Validate ISO 8601 Dates (with Leap Year Awareness)

/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/

A quick sanity check before passing dates to new Date(). Catches 2025-13-01 (invalid month) and 2025-02-30 (impossible day) that JavaScript silently coerces into valid dates.

4. Extract All Numbers (Including Decimals and Negatives)

/-?\d+(?:\.\d+)?/g

Grabs -3.14, 42, 0.001 from mixed text. Use this when scraping prices, measurements, or coordinates from unstructured data.

5. Strip ANSI Escape Codes from Terminal Output

/\\x1b\[[0-9;]*m/g

Ever piped npm test output to a file and got garbage? This pattern removes all color/formatting codes, leaving clean text you can parse or grep.

The Tool That Makes This Fast

I test every pattern above in CodeToolbox Regex Tester before pasting it into production code. Here's why:

Instant visual feedback — highlighted matches update as you type, so you see the greedy/lazy difference immediately
Capture group breakdown — each group is listed separately, so you know exactly what $1, $2 will contain
No data leaves your browser — all processing is local JavaScript, so you can test on real log files and API responses

No signup, no ads, no server uploads. Just a fast regex playground that stays out of your way.

These five patterns cover ~80% of the regex work I do in a typical week. What's the one regex pattern you find yourself writing over and over? I'd love to add it to my toolkit 🙂

encodeURI vs encodeURIComponent: The JavaScript URL Encoding Trap

zhihu wu — Sun, 31 May 2026 13:05:38 +0000

Most JavaScript developers have been bitten by URL encoding at some point. You build a query string, pass it to fetch(), and suddenly your API returns 400. The culprit? You used encodeURI() when you should have used encodeURIComponent().

The Core Difference

JavaScript gives us two encoding functions, and they serve different purposes:

encodeURI() is designed for complete URLs. It keeps URL structure characters intact: /, ?, &, =, #, :, @, $, +, and ,. Use it when you have a full URL string and want to make it safe for transmission.
encodeURIComponent() is for individual parameter values. It encodes everything except A-Z a-z 0-9 - _ . ! ~ * ' ( ). This is what you want for query string values, path segments, and any data embedded in a URL.

The Classic Bug

Here's the mistake everyone makes at least once:

// WRONG — the @ and = break as literal URL characters
const email = "user@example.com";
const url = "https://api.example.com/search?email=" + encodeURI(email);
// Result: https://api.example.com/search?email=user@example.com
// The @ is interpreted as a URL authority separator!

The fix:

// RIGHT — all special chars are percent-encoded
const url = "https://api.example.com/search?email=" + encodeURIComponent(email);
// Result: https://api.example.com/search?email=user%40example.com

Double-Encoding: The Silent Killer

If you encode an already-encoded string, the % sign itself gets encoded to %25. hello%20world becomes hello%2520world. This is maddening to debug because it looks almost right. The fix: always decode first to see what you're actually working with.

The Modern Approach

In 2026, you rarely need to manually encode URLs. The URL and URLSearchParams APIs handle encoding automatically:

const params = new URLSearchParams({ email: "user@example.com", q: "hello world" });
const url = "https://api.example.com/search?" + params.toString();
// https://api.example.com/search?email=user%40example.com&q=hello+world

When You Still Need Manual Encoding

Sometimes you're debugging logs, comparing API responses, or working with encoded strings from external systems. That's when a quick encoder/decoder tool saves you from counting percent signs in your terminal.

Handy tool: I keep CodeToolbox URL Encoder bookmarked for those moments — paste any string, encode or decode instantly, all local processing so no data leaves your browser.

TL;DR: encodeURI() for full URLs. encodeURIComponent() for values. URLSearchParams for everything new. And if you see %25 in your output, you've double-encoded — decode and start over.

DEV Community: zhihu wu

3 Times You Need Base64 (and One Time You Definitely Don't)

When Base64 Makes Sense

1. Embedding Small Images in HTML/CSS

2. Sending Binary in JSON APIs

3. Debugging Tokens and Auth Headers

When NOT to Use Base64

Your JSON Is Valid... Until It's Not: Common Parse Errors and How to Fix Them

1. Trailing Commas (The #1 Offender)

2. Smart Quotes vs. Straight Quotes

3. Unquoted Keys

4. The Invisible BOM

5. Single Quotes

Debugging Tip

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

Stop Copy-Pasting Regex You Don't Understand: 5 Patterns Explained

1. Email Validation: The Pattern Everyone Gets Wrong

2. URL Extraction: Greedy vs. Lazy Trap

3. IP Address Extraction: Backreference Magic

4. Date Extraction (ISO 8601): Character Classes Done Right

5. The "Everything Between Tags" Problem

The Debugging Workflow I Actually Use

Why Your API Calls Break: A Developer's Guide to URL Encoding

Why Your API Calls Break: A Developer's Guide to URL Encoding

1. The Double-Encoding Trap

2. The + vs %20 Confusion

3. Encoding the Wrong Thing

Quick Debugging Workflow

Modern Alternative: URLSearchParams

Your Website Images Are Killing Your SEO — Here's How to Fix It

The Hidden Speed Killer on Every Website

The Fix Is Simpler Than You Think

A Tool That Actually Respects Your Privacy

The Bottom Line

3 Base64 Tricks Every Developer Should Know

1. Decode JWT Payloads Without a Library

2. Peek Inside HTTP Basic Auth Headers

3. Embed Images Without Extra HTTP Requests

3 JSON Formatting Tricks That Save Me Hours Every Week

The Problem

1. Pretty-Print First, Debug Later

2. Collapse Deeply Nested Structures

3. Validate JSON Before It Reaches Production

Beyond UUID v4: v7, ULID, and the Future of Unique IDs

The Classic: UUID v4

The Upgrade: UUID v7 (Time-Ordered)

The Compact Alternative: ULID

Decision Framework

Quick Testing

The Takeaway

Cron Expressions for CI/CD — Beyond Crontab Basics

Cron in the Modern Stack

The Trick People Miss

Quick Testing Tip

Loan Math for Developers: 4 Levers That Save Thousands

The Formula, Deconstructed

The Levers You Can Pull

1. Extra Principal Payments

2. Biweekly Instead of Monthly

3. The 15-Year vs 30-Year Tradeoff

4. Rate Shopping Actually Matters

Try It Yourself

5 Regex Patterns That Will Save You Hours of Debugging

1. Extract Key-Value Pairs from Query Strings

2. Match Paired HTML Tags (Without Crossing Boundaries)

3. Validate ISO 8601 Dates (with Leap Year Awareness)

4. Extract All Numbers (Including Decimals and Negatives)

5. Strip ANSI Escape Codes from Terminal Output

The Tool That Makes This Fast

encodeURI vs encodeURIComponent: The JavaScript URL Encoding Trap

The Core Difference

The Classic Bug

Double-Encoding: The Silent Killer

The Modern Approach

When You Still Need Manual Encoding

2. The `+` vs `%20` Confusion