Blog

What this blog covers

This is the technical writing side of Online Dev Tools. Posts here go deeper than the tool pages — they explain workflows, document decision-making processes, and cover the kind of context that is useful when you are applying a tool to a real engineering problem rather than just learning what it does.

The topics are tightly coupled to the tools on the platform. If there is a guide about CSP hardening, there is a corresponding CSP Analyzer tool. If there is a post about log triage, there is a Log Explorer to work through the examples. The intent is that guides and tools reinforce each other: use the tool to process data, read the guide to understand what the output means and what to do next.

Topics covered

Incident response and log analysis. When something breaks in production, the first job is cutting through noise to find the signal. Posts in this area cover how to approach log triage, how to structure your investigation, and how to get from a raw stream of error output to a specific lead. The Log Triage Checklist and the Browser Incident Response Toolbelt both fall into this category.

Security engineering. CSP configuration, cryptographic hashing, HMAC, token inspection — the security-focused posts on this blog are written for engineers who implement security controls, not for security salespeople. The CSP hardening walkthrough covers the full lifecycle from report-only mode through to enforcement with real testing steps. The hashing vs HMAC guide explains when to use each, how to pick an algorithm, and where engineers commonly make mistakes that introduce vulnerabilities.

Network and domain intelligence. DNS, WHOIS, IP data, and domain investigation are underused engineering skills. The WHOIS and domain intelligence guide walks through how to read registrar data, identify abuse signals, and build investigation workflows around what WHOIS actually tells you — including its limits.

API debugging and data formats. JSON is everywhere, and malformed JSON payloads are a common source of debugging friction. The JSON formatting guide covers how consistent formatting, key sorting, and schema validation make API debugging faster and code review cleaner.

How posts connect to tools

Every post on this blog is written to be read alongside an actual tool. The guides are not abstract — they describe real inputs, real outputs, and real decisions. After reading a post, the next step is usually to open the corresponding tool and apply the workflow to your own data.

The Learn hub organizes the same content by skill area rather than by publication date. If you are looking for everything related to a specific topic — JSON, security, network tools, debugging — the Learn hub is the better starting point. The blog is the right place if you want the most recently published content or are following along with new additions.

Posts are published irregularly. There is no content calendar or posting schedule. New guides go up when there is something worth writing, not on a fixed cadence. The RSS feed is the best way to follow new posts without checking back manually.

Who this is written for

The assumed reader is a working engineer — someone who is comfortable with code, knows their tooling, and is looking for specific, actionable information rather than introductory content. Posts do not spend time on background that any developer would already know. They get to the relevant decision, the specific configuration, or the concrete debugging step as quickly as possible.

If you are new to a topic — CSP, cryptographic hashing, WHOIS lookups — the posts include enough context to make them useful without prior expertise in that specific area. But the writing assumes technical literacy as a baseline. If something is unclear or needs more context, the contact form is the right place to ask.

How to use posts alongside tools

/csp-analyzer">CSP Analyzer and see the findings in real time. Reading about log triage is more actionable when you can paste a log sample into the Log Explorer and step through the filtering workflow described in the post. Reading about WHOIS investigation is more concrete when you can run an actual lookup in the WHOIS Lookup and see the fields being discussed.

The recommended pattern is to read the guide first to understand the concepts and the workflow, then use the tool to apply that workflow to your own data. The guides explain the why — why certain CSP directives create risk, why HMAC is preferable to plain hashing in certain contexts, why WHOIS data degrades in usefulness as domains get older. The tools handle the mechanical work of processing your actual inputs without writing code or installing anything.

If you are working through an incident or a security review and want structured guidance on what to look for, the blog is a better starting point than the tools index. If you already know what you need to do and just need the tool to do it, the All Tools page is the faster path. Both entry points are valid — the content is designed to be useful whether you come from the editorial side or the utility side.

What is coming next

Upcoming guides will cover DNS lookup workflows, HTTP header analysis for security reviews, a deeper look at UUID versions and when each one is appropriate for distributed systems, and a practical guide to using the Diff Checker for tracking API schema changes across releases. Topics are added when there is a real workflow to describe, not to fill a publishing calendar. If there is a specific tool or workflow you want covered, the contact form is the right place to suggest it.