Everyday Developer Utilities Roadmap: Encoding, Timestamps, and Diffing

This isn't a dependency chain — you don't need Stage 1 to understand Stage 3. It's an honest ordering of the small, everyday developer tools you'll actually reach for, roughly in the frequency a typical week surfaces them: encoding a query string before lunch, converting a timestamp from a bug report after lunch, diffing two config files before a deploy, and previewing a README before it ships. None of these skills are hard. What's hard is knowing the one or two details in each that cause real bugs — that's what each stage below is actually about.

Every URL is built from characters, but not every character is legal in every part of one. A space, an ampersand, or a non-ASCII character has to be percent-encoded — replaced with a %followed by its byte value in hex — before it's safe to put inside a URL at all. That's the entire mechanism behind percent-encoding, and it's worth being able to reason about by hand before you ever paste something into a tool.

The part that actually trips people up when they start to learn URL encoding isn't the mechanism — it's that there are three different encoding rules depending on where the text sits, and mixing them up produces a URL that looks correct but silently breaks. Encoding a full URL only touches characters that are illegal everywhere (spaces, unescaped Unicode); it deliberately leaves &, =, and /alone because those are structural. Encoding a single component — a value you're about to insert into a query string — has to escape those same structural characters, or a value containing & quietly splits into extra parameters. And form encoding (application/x-www-form-urlencoded) adds its own quirk on top: a literal space becomes +, not %20, a leftover from HTML forms that still governs how browsers serialize FormData today.

full URL:        https://example.com/search?q=hello world → https://example.com/search?q=hello%20world
component:       "a&b"  →  a%26b
form-encoded:    "a b"  →  a+b

Get this wrong and the bug is invisible in the browser's address bar but very visible in a server log or an analytics dashboard, once a parameter that should have three values has one. The full mechanics — including which characters each mode leaves untouched and why — are covered in the URL Encoder/Decoder guide. It's the tool you'll reach for more than any other on this list, because query strings show up in nearly every request you debug.

Once URLs stop being mysterious, the next everyday developer tools problem is time — specifically, the moment someone hands you a bare integer and calls it a timestamp. Unix timestamp basics start with one idea: a Unix timestamp is a count of elapsed units since January 1, 1970 UTC (the epoch), with no timezone attached and no unit specified by the number itself. Both of those omissions are where the real bugs live.

The unit-ambiguity trap is the one you'll hit constantly: the same instant in time is roughly 1735689600 in seconds, 1735689600000 in milliseconds, 1735689600000000 in microseconds, and 1735689600000000000in nanoseconds — and a log line or API response rarely tells you which one it's giving you. Paste a millisecond value into code expecting seconds and you land somewhere in the 48th century; paste a seconds value into code expecting milliseconds and you land in 1970. The only reliable check is the digit count, since each unit adds roughly three more digits than the last.

seconds:       1735689600
milliseconds:  1735689600000
microseconds:  1735689600000000
nanoseconds:   1735689600000000000

Timezone rendering is the second trap: the integer itself has no timezone, so “January 1” can be true in UTC and false in the reader's local zone depending on the hour. And there's a structural limit worth knowing even if it feels distant — the Year 2038 problem, where a signed 32-bit seconds counter overflows on January 19, 2038, which is still a live concern in older systems and embedded software that never moved to 64-bit time. All three of these — unit detection, timezone-aware rendering, and the 2038 ceiling — are walked through in full in the Unix Timestamp Converter guide, which is the pillar reference for this stage.

Encoding and timestamps are about getting a single value right. Diffing is about noticing exactly what changed between two versions of something larger — a config file, a response body, a paragraph of copy — and that requires picking the right granularity on purpose, not by default.

Line-level diffing is the right default for source code and structured files: it reports which whole lines were added, removed, or changed, which is exactly the unit a code review or a config audit cares about. Word-level diffing matters for prose and generated text, where a single line might change in three places and a line-level diff would just tell you “this line is different” without saying how. Knowing which one you actually need before you start comparing saves you from misreading a diff that's technically correct but answering the wrong question.

Two settings decide whether a diff shows you signal or noise. Whitespace-insensitive comparison ignores differences in indentation and trailing spaces — indispensable when a file was reformatted by a linter and you only care about logic changes. Case-insensitive comparison does the same for capitalization, useful when comparing values that are semantically identical regardless of case (a header name, a config key). Skip both and a diff full of formatting churn will bury the one line that actually matters.

--- a/config.json
+++ b/config.json
@@ -2,3 +2,3 @@
   "env": "staging",
-  "retries": 3,
+  "retries": 5,
   "timeout": 30

That output format — ---/+++ file headers, @@ hunk markers, and -/+ line prefixes — is the unified diff format, the same one git diff prints and patchconsumes. Recognizing it on sight means a diff pasted into a PR comment or a CI log is immediately readable without opening a repo. It's covered end to end, alongside line vs. word modes and whitespace/case options, in the Diff Checker guide.

The last everyday habit worth building is checking how Markdown actually renders before it ships — a README, a changelog entry, a doc comment. Markdown-to-HTML rendering follows CommonMark for the core syntax (headings, emphasis, lists, links) but most places you write Markdown — GitHub, GitLab, most doc tools — layer GitHub Flavored Markdown (GFM) extensions on top: tables, fenced code blocks with language hints, task lists, and automatic linking of bare URLs. Writing Markdown without previewing it means shipping a table that never renders as a table because the platform you tested against wasn't the one you write for day to day.

The detail worth taking seriously, not glossing over, is the security implication of rendering raw HTML embedded inside Markdown from an untrusted source. Markdown syntax permits literal HTML tags inline, and a renderer that passes that HTML straight through without sanitizing it will execute a <script> tag or an onerrorhandler pasted by someone else just as readily as it renders a bold word. That's a real cross-site-scripting vector the moment Markdown input comes from anywhere other than yourself — a user comment, an imported file, a webhook payload — and it's the reason a trustworthy preview tool sanitizes rendered HTML by default rather than treating sanitization as an opt-in feature.

The full rundown — CommonMark vs. GFM feature by feature, and exactly what a safe renderer strips before it shows you the result — is in the Markdown Preview guide. It's the natural last stop on this roadmap: by the time you're previewing rendered output, you've already spent a week encoding URLs, converting timestamps, and diffing text — the same small-tool instinct applied to one more everyday task.