DEV Community: zhihu wu

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.

UUIDs in Practice — When Auto-Increment Falls Short

zhihu wu — Fri, 29 May 2026 13:05:09 +0000

Most of us learned databases with auto-increment IDs. id INT AUTO_INCREMENT is in every tutorial. It works — until it doesn't.

The Case for Auto-Increment

Auto-increment integers are fast, small (4 bytes), and naturally ordered. For a single-database app with one writer, they're perfect. But real systems rarely stay that simple.

Where Auto-Increment Fails

Distributed writes. When you have multiple API servers writing to the same database, auto-increment creates a bottleneck. Someone has to own the counter.

Multi-tenant databases. Merging data from different shards or regions? Integer ID collisions are guaranteed. You'll spend days resolving conflicts.

Data exposure. /api/users/1, /api/users/2... users and competitors can estimate your growth, user count, and order volume in minutes.

Offline-first apps. Can't generate IDs while disconnected if you need a central sequence. UUIDs work anywhere, anytime.

UUID v4: The Distributed-Friendly Default

UUID v4 generates 122 random bits via a cryptographically secure PRNG — no coordination needed. The collision probability is astronomically low (1 in 2.7×10^18). PostgreSQL handles them natively:

CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  email TEXT NOT NULL
);

The 16-byte storage overhead is negligible for modern systems.

The Trade-off

UUIDs aren't sortable by insertion order and can fragment B-tree indexes. For write-heavy workloads, consider UUID v7 (time-ordered) or ULID. But for 95% of projects, v4 works fine.

Quick Tip

When setting up a new project, I generate a batch of UUIDs to copy into my seed files or test fixtures. There's a dead-simple generator at codetoolbox.pro/tools/uuid-generator — no signup, no uploads, all browser-side. Just set the count and go.

What do you use for primary keys in your projects?

How Loan Amortization Actually Works (and How to Save Thousands)

zhihu wu — Sun, 24 May 2026 13:03:25 +0000

Most developers understand compound interest for investments. But with debt — mortgages, auto loans, student loans — the same math works against you.

The Formula Behind Every Loan Payment

Every fixed-rate loan uses this amortization formula:

M = P × [r(1+r)^n] / [(1+r)^n − 1]

M = monthly payment, P = principal, r = monthly rate (annual ÷ 12), n = total payments.

The intuition: this exact amount drives your balance to zero by the final payment.

The Front-Loading Trap

On a $250k mortgage at 6.5% over 30 years, your first payment is roughly 85% interest, 15% principal. By year 15 it's 50/50. In the final year, over 95% goes to principal.

This means every extra dollar toward principal early has an outsized effect. That $100 extra in month 1 saves you 359 months of interest on that $100.

Real Numbers

$250k at 6.5% / 30yr: $1,580/mo, total $568,861
Same at 15yr: $2,178/mo, total $392,069 → saves $176,792
$100/mo extra on 30yr: Saves ~$49k, pays off 4.5 years early

3 Simple Strategies

Bi-weekly payments: 26 half-payments = 13 full payments/year. Knocks ~5 years off a 30yr mortgage.
Round up: Pay $1,600 instead of $1,580. The $20 extra compounds.
Refi but keep old payment: When rates drop, keep paying the old amount. The difference is pure principal.

I built a free loan calculator with full amortization schedules and visual breakdowns. Runs in your browser, no signup.

Understanding amortization isn't just for homeowners — car loans, personal loans, any installment debt. The math is identical. The earlier you act, the more you save.

My 4-Step Regex Debugging Workflow (That Actually Saves Time)

zhihu wu — Thu, 21 May 2026 13:07:23 +0000

I've written hundreds of regular expressions over the years, and I still get them wrong on the first try. Here's the debugging workflow I've settled on that consistently gets me from "why isn't this matching" to "oh, that's why" in under a minute.

Step 1: Isolate One Pattern at a Time

The most common mistake I see (and make) is testing a monster regex all at once. If you're validating an email with a complex pattern and it's not working, break it down: test just the local part, then the domain, then combine them. This alone has saved me hours of staring at a wall of backslashes and brackets.

Step 2: Check Your Quantifier Greediness

This one bites everyone. A pattern like <.*> against "<div>hello</div>" matches the entire string, not just the opening tag. The fix: add ? to make it lazy — <.*?>. I can't count how many "my regex is broken" posts on Stack Overflow boil down to this. Whenever a pattern matches too much, my first instinct is to check for greedy quantifiers.

Step 3: Toggle the Flags

Flags change everything. hello matches "hello" — but add the i flag and hello now matches "HELLO", "Hello", and "hElLo". The ^ anchor matches the start of a string by default, but with the m (multiline) flag, it matches the start of each line. I often toggle the g (global) flag off during debugging to focus on the first match, then turn it back on to check all occurrences.

Step 4: Use a Real-Time Tester

This is the game-changer. Rather than write-test-rewrite cycles in my code editor, I use a live regex tester that highlights matches as I type. Seeing matches highlighted instantly — and seeing capture groups broken out individually — makes pattern bugs obvious in seconds. I use CodeToolbox Regex Tester because it runs entirely in the browser (no data uploads) and includes presets for common patterns like email, URL, and IPv4 to use as starting points.

The complete workflow takes less than a minute once it becomes habit: isolate → check greediness → toggle flags → test live. These four steps have saved me more debugging time than any regex cheatsheet ever has.

What's your go-to regex debugging trick? I'd love to hear what works for you in the comments.

5 Markdown Tricks Every Developer Should Know (That Aren't in the Cheat Sheet)

zhihu wu — Tue, 19 May 2026 13:06:43 +0000

We all know the basics: **bold**, *italic*, # Headings. But Markdown (especially GitHub Flavored Markdown) has some lesser-known tricks that can make your READMEs, docs, and PR descriptions much more polished. Here are five I use constantly.

1. Collapsible Sections with `<details>`

Got a long README? Hide secondary content behind expandable sections:

<details>
<summary>Click to see the full changelog</summary>

- v2.1: Added dark mode
- v2.0: Complete rewrite
- v1.0: Initial release

</details>

This renders as a clickable toggle. Perfect for changelogs, setup instructions, or verbose examples you don't want cluttering the main view. GitHub, GitLab, and most static site generators support this.

2. Auto-Linking to Headings

GitHub auto-generates anchor links for every heading. You can link to any section with a simple relative link:

See the [Installation](#installation) section for setup instructions.

The rule: lowercase everything, replace spaces with hyphens, remove punctuation. So ## API Reference (v2) becomes #api-reference-v2.

Bonus: This works across files too — [See docs](docs/API.md#authentication).

3. Task Lists in PR Descriptions

GFM supports interactive checkboxes:

- [x] Add unit tests
- [x] Update documentation
- [ ] Bump version number
- [ ] Deploy to staging

These render as actual checkboxes on GitHub Issues and PRs. Use them in PR templates to create a checklist the author can tick off before merging. They also show up in project boards as trackable items.

4. Escaping Backticks Inside Inline Code

Sometimes you need to show a literal backtick character inside inline code. The trick? Use double backticks as delimiters:

To display a variable, use `` `varname` `` in your template.

Renders as: To display a variable, use `varname` in your template.

The outer double-backtick pair lets you nest single backticks inside. Add a space before/after the inner backtick for readability.

5. Mermaid Diagrams in Fenced Code Blocks

Many platforms (GitHub, GitLab, Notion) support Mermaid diagrams directly in Markdown. Just use mermaid as the language tag:

```

mermaid
graph TD
    A[User] --> B[Login Page]
    B --> C{Valid?}
    C -->|Yes| D[Dashboard]
    C -->|No| E[Error Message]


```
```

`

This renders a flowchart directly in your README — no external tools, no image exports. Mermaid supports flowcharts, sequence diagrams, Gantt charts, class diagrams, and more.

---

## The Best Way to Learn? Preview in Real Time

The fastest way to get comfortable with Markdown is to see it render as you type. I use [CodeToolbox Markdown Preview](https://codetoolbox.pro/tools/markdown-preview.html) when drafting READMEs — it's free, runs entirely in the browser (nothing gets uploaded), and supports full GFM including tables, task lists, and syntax-highlighted code blocks.

What Markdown tricks do you use that aren't in the standard cheat sheet? Drop them in the comments 👇