DEV Community: Mubeen Khan

The one-line SQL query that broke code review

Mubeen Khan — Sun, 15 Nov 2026 10:34:51 +0000

I once reviewed a pull request where the entire database migration was one line. Four hundred and twelve characters of SQL, no line breaks, no indentation, a JOIN buried somewhere in the middle like a landmine. The query was correct. It also took me twenty minutes to be sure it was correct, because I could not read it.

That is the whole case for a SQL formatter. It does not make your query faster. It does not fix your logic. It makes the query readable enough that a human can spot the bug before it ships.

Formatting is not cosmetic

A formatter does two honest things. First, it puts one clause per line: SELECT, FROM, WHERE, GROUP BY, ORDER BY. Second, it indents the parts that belong together, so a JOIN condition sits under its JOIN and a subquery is visibly nested inside its parent. That is it. No magic, no rewriting. The formatted query does exactly what the original did, because only whitespace and casing changed.

The bug I was hunting in that PR turned out to be a missing condition in the WHERE clause. On one line, the WHERE clause looked like a wall of text and my eyes slid right past it. Formatted, the missing condition was obvious in about four seconds, because the list of conditions was vertical and one item was simply absent.

The dialect trap nobody warns you about

Here is where most people pick the wrong formatter: SQL is not one language. MySQL uses backticks for identifiers. SQL Server uses square brackets. PostgreSQL uses double quotes. BigQuery has its own ideas about everything. A formatter that does not know your dialect will happily "fix" syntax that was never broken, or choke on syntax that is perfectly valid in your database.

So the first question a good formatter asks is not "how many spaces" but "which database". Standard SQL, MySQL, PostgreSQL, SQLite, SQL Server, Oracle, BigQuery, Snowflake, Redshift: each one parses differently. If your formatter treats them all the same, it is guessing, and guessing with production queries is a bad habit.

Minify is the opposite direction, and it has a use

Formatting spreads a query out. Minifying crushes it into one line. That sounds like going backwards, until you need to paste a query into a URL parameter, a log line, or a config value where newlines are not welcome. Minify is a transport format, not a reading format. The rule is simple: format for humans, minify for machines, and never confuse the two.

One warning about minifying: a careless minifier will strip a comment that your query actually needs, or join two tokens that were only separated by whitespace. A good one leaves string literals and comments alone. If yours does not, find another one.

Your queries should never leave your browser

This matters more than people admit. The queries you format are often production queries. They contain real table names, real column names, sometimes real customer IDs baked into a WHERE clause. A formatter that uploads your SQL to a server to format it is a data leak wearing a tool costume.

The safe version runs entirely in your browser. Paste, format, copy, done. Nothing is uploaded, nothing is stored, nothing is logged. If a tool cannot promise that, do not paste production SQL into it. I built a free one that works exactly this way, with dialect selection, keyword casing, indentation options and a minify mode: it formats MySQL, PostgreSQL, SQLite, SQL Server, Oracle, BigQuery and more, all in your browser. You can try it here: https://www.theutilityhub.online/tools/sql-formatter

A small habit that pays off

Before you paste a query into a pull request, a migration file, or a chat message to a colleague, run it through a formatter. It takes three seconds. The person reading it, which is often future you, will be able to see the structure instead of decoding a wall of text. And the next time a WHERE condition goes missing, you will spot it in four seconds instead of twenty minutes.

Base64 makes your image 33% bigger. Here is when that is still the right call

Mubeen Khan — Sat, 14 Nov 2026 10:31:23 +0000

Every frontend developer eventually meets the same suggestion: just inline the image as Base64. It sounds like free performance, one less HTTP request, no separate file to manage. And then someone points out the catch: Base64 encoding makes the image about 33% bigger. So is inlining ever worth it, or is it a trick that costs more than it saves?

The honest answer is that it depends entirely on the size of the image and where it lives. The 33% overhead is real and unavoidable, it comes from the encoding itself, but the request you save is also real. For a tiny icon, the trade wins easily. For a hero photo, it loses badly. The skill is knowing where the line sits.

Why Base64 is 33% bigger

Base64 exists to move binary data through systems that only understand text. An image file is bytes. HTML, CSS, JSON and email are text. Base64 converts every 3 bytes of image into 4 characters of plain ASCII, which is why the output is always roughly one third larger than the file you started with.

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

That data:image/png;base64, prefix is called a data URI. Everything after the comma is the image, encoded as text, embedded directly in your page. No separate file, no extra request, no server round trip. The browser decodes it and renders the image exactly as if it had downloaded a file.

The encoding is the easy part. The decision is the hard part.

When inlining wins: small, repeated, critical images

Inline an image as Base64 when it is small, when it appears on every page, or when it must render before anything else loads. The classic winners are logos, icons, tiny UI graphics and one-pixel tracking or spacer images.

A 2KB logo becomes about 2.7KB of text. That is nothing, and in exchange you remove a render-blocking request from the critical path. Your logo appears with the first paint instead of after the browser fetches a second file. The same logic applies to the small icons in a button set or a navigation bar: ten tiny icons as ten separate files means ten requests; inlined, they ride along with the HTML you were already downloading.

Email is the other place where inlining earns its keep. Many email clients block remote images by default, so a remote logo shows up as a broken box until the reader clicks "show images". An inlined logo renders immediately, because it was inside the message all along.

When inlining loses: anything large or cacheable

Do not inline a photo. A 200KB product photo becomes about 267KB of text baked into your HTML, and that text downloads again on every single page load, because an inlined image cannot be cached separately from the page around it. A linked image file downloads once and then sits in the browser cache for every page after that.

The same applies to images that change often. Update a linked logo and every visitor gets the new one on their next visit. Update an inlined logo and you have to change every page, email or stylesheet that contains the old string, and anyone with a cached copy of the old page keeps seeing the old logo.

A practical rule of thumb: if the image is under about 10KB, inlining is usually a win. Between 10KB and 50KB, it depends on how critical the image is. Above that, link the file and let the browser cache do its job.

The conversion itself takes ten seconds

Converting an image to Base64 is not a server job and it should never involve uploading your file anywhere. The browser already has everything it needs: the FileReader API reads the file and hands you the data URI, all inside your own tab.

const reader = new FileReader();
reader.onload = () => {
  const dataUri = reader.result; // "data:image/png;base64,..."
  document.querySelector('img').src = dataUri;
};
reader.readAsDataURL(file);

What you get back is the full data URI, ready to paste into an <img> tag, a CSS background-image, or a JSON payload. If you only need the encoded text without the prefix, strip everything up to the comma. The same string also decodes in reverse: paste a data URI into a decoder and you get the image back, which is how you check what an unfamiliar Base64 blob actually contains before trusting it.

One trick that makes the 33% hurt less

If the image is a JPEG or WebP, re-encoding it at a lower quality before converting can shrink the Base64 output by far more than the encoding adds. A 120KB screenshot re-encoded as JPEG at 80% quality might drop to 40KB, and its Base64 form lands around 53KB, smaller than the original file was. The encoding overhead stays 33%, but 33% of a much smaller number is a much smaller number.

This is worth doing only for images where a little quality loss is invisible, photos and screenshots qualify, crisp logos and line art do not. And it only makes sense when the image was already a candidate for inlining: small, repeated, or critical. Re-encoding a hero photo to make it inlineable is solving the wrong problem.

The decision, in one paragraph

Inline images under about 10KB, especially logos and icons that appear everywhere or must render instantly. Link everything larger, everything that changes, and everything the browser should cache. Convert locally, never upload an image to a random site to get its Base64 string, because the file you upload is your file. And when you do inline, re-encode JPEGs and WebPs first, so the 33% overhead applies to the smallest file you can honestly produce.

I built a free image to Base64 converter that does the whole job in your browser: drop an image in, get the raw Base64, the full data URI, and ready-to-paste HTML, CSS and Markdown snippets, with an optional re-encode step to shrink the output first. It also decodes in reverse, so you can paste any data URI back in and preview the image it holds. No upload, no signup, and you can try it here: Image to Base64 Converter.

The 33% is not a reason to avoid Base64. It is the price of the trick, and for small images, it is a price worth paying.

JSON and XML do not describe data the same way, and every converter has to pick a side

Mubeen Khan — Fri, 13 Nov 2026 10:33:40 +0000

Every API speaks JSON now. Every legacy system still speaks XML. Sooner or later you have to move data from one to the other, and that is when you discover the two formats do not describe data the same way at all.

JSON has six kinds of value: objects, arrays, strings, numbers, booleans and null. XML has elements, attributes and text. There is no one-to-one mapping between them, so every converter has to make four decisions for you, and most of them make those decisions silently.

Decision 1: what is the root?

XML demands exactly one root element. JSON does not. Your JSON might be an object, an array, or even a single string, and the converter has to wrap it in something.

{ "name": "Ana", "city": "Karachi" }

becomes:

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <name>Ana</name>
  <city>Karachi</city>
</root>

That <root> is a choice, not a fact. Some converters name it after your file. Some let you pick the name. If the system receiving your XML expects <order> or <catalog>, a converter that hardcodes <root> hands you a file you have to edit by hand. Pick one that lets you name the root before you convert, not after.

Decision 2: what happens to arrays?

XML has no array type. JSON does. So when the converter meets this:

{ "tags": ["new", "sale", "featured"] }

it has to choose. The honest choice is to repeat the element:

<tags>
  <item>new</item>
  <item>sale</item>
  <item>featured</item>
</tags>

The lazy choice is to join the values into one string, new,sale,featured, which destroys the structure and makes the data unparseable on the other side. If you are converting a list of products, orders or line items, repeated elements are the only representation that survives a round trip. Check what your converter does with an array before you trust it with a real payload.

Decision 3: attributes or elements?

XML has attributes. JSON does not. So a converter has to decide whether {"id": 42} becomes <product><id>42</id></product> or <product id="42"></product>. Both are valid XML. They mean different things to the system reading them.

The convention most tools use is a prefix: keys starting with @ become attributes, and a special #text key holds the text content of an element. It is not a standard, it is a handshake, but it is the handshake almost every converter understands:

{
  "product": {
    "@id": "42",
    "@currency": "USD",
    "#text": "Running shoes"
  }
}

<product id="42" currency="USD">Running shoes</product>

If your converter does not support that convention, you cannot express attributes at all, and every piece of metadata becomes a child element whether the receiving system wants it there or not.

Decision 4: what about null?

JSON has null. XML has no equivalent. A converter meeting "discount": null has three options: emit an empty element <discount/>, skip the key entirely, or mark it explicitly with xsi:nil="true". Each one means something different. An empty element can mean "present but blank". Omitting the key can mean "not applicable". Only xsi:nil says, unambiguously, "this value is null". For a SOAP service or a config file, the wrong choice here is a silent bug: the field looks converted, but the receiving system reads it as something else entirely.

The keys that are not legal XML

There is one more trap, and it is the one that breaks conversions most often. JSON keys can be almost anything. XML element names cannot start with a digit, cannot contain spaces, and cannot contain most punctuation. A key like "2fa_enabled" or "first name" is perfectly good JSON and invalid XML.

A good converter repairs those names and tells you it did so, turning 2fa_enabled into something like _2fa_enabled and flagging the change. A bad converter either crashes on the first bad key or emits XML that no parser will accept, and you only find out when the other system rejects the whole file.

Why this still matters in 2026

Nobody writes new systems in XML. But RSS feeds, sitemaps, SOAP APIs, banking integrations, government portals, old ERPs and configuration files all still run on it. The JSON-to-XML bridge is not a legacy curiosity, it is a weekly task for developers who integrate with anything older than five years.

The conversion itself is simple once you know the four decisions: name your root, repeat elements for arrays, use the @ prefix for attributes, and decide what null means before you convert. Get those four right and the output is XML any parser will accept.

I built a free JSON to XML converter that makes all four choices visible instead of hiding them: you name the root and array items, toggle the XML declaration and indentation, pick how nulls are handled, and it flags every key it had to repair. It runs entirely in your browser, so nothing you paste is uploaded, and you can try it here: JSON to XML Converter.

The conversion is not the hard part. Knowing what the converter decided for you is.

Stop stripping HTML with regex: the browser already knows the plain text

Mubeen Khan — Thu, 12 Nov 2026 10:30:41 +0000

Every developer has written this line at some point:

const text = html.replace(/<[^>]*>/g, "");

It looks reasonable. It passes the first test. Then it meets real HTML and falls apart in five different ways at once.

The problem is not your regex. The problem is that HTML is not a regular language, and no pattern can understand it the way a parser can.

Where the regex breaks

Take a simple email template:

<p>Hi Ana,</p>
<p>Your order <strong>#4821</strong> ships on <time>Friday</time>.</p>
<ul>
  <li>Tracking link inside your account</li>
  <li>Free returns for 30 days</li>
</ul>

Strip the tags with a regex and you get:

Hi Ana,Your order #4821 ships on Friday.Tracking link inside your accountFree returns for 30 days

Every paragraph boundary is gone. The list items run together. The text is technically tag-free and completely unreadable. A regex sees characters, not structure. It cannot know that </p> means "new paragraph" or that <li> means "new line with a bullet".

Then there are the cases where it silently corrupts content. A <script> block full of comparison operators becomes text. A > inside an attribute value (<a title="a > b">) ends the "tag" early and leaves markup in your output. An HTML entity like & stays as the literal characters & instead of becoming &. And   becomes a non-breaking space that looks identical to a normal space but breaks every search, split and comparison you run on the result afterwards.

The browser already solved this

Here is the thing most people miss: you do not need a library to extract text from HTML correctly. The browser ships with a real HTML parser, and it is one function call away.

const doc = new DOMParser().parseFromString(html, "text/html");
const text = doc.body.innerText;

DOMParser builds a real document from your markup. It is inert: scripts never run, images and stylesheets never load, nothing is fetched. Then innerText walks that document the way a browser renders it: block elements get line breaks, paragraphs get blank lines between them, <br> becomes a newline, list items get their markers, table cells get separated. The parser handles the entities, the malformed nesting, the unclosed tags. All the edge cases your regex was about to meet have already been handled, by the same engine that renders every web page you have ever opened.

There are two details worth knowing. First, innerText is aware of what is visible, so content inside <script> and <style> is excluded, while textContent would include it. If you want the readable text of a page, innerText is the one you want. Second, this runs entirely in the browser. Nothing is uploaded, which matters when the HTML you are cleaning is a client email template or a page full of internal links.

The options that make the output actually usable

A raw text dump is only half the job. Three small choices turn it into text you can paste somewhere and trust:

Keep the link destinations. A link that reads "read the docs" is useless in plain text unless the URL survives. Writing it as read the docs (https://example.com/docs) keeps the destination attached to the words.

Keep image alt text. In plain text, an image is invisible, but its alt text is often the only description of what was there. Writing it as [Product photo: blue running shoes] preserves the information instead of silently dropping it.

Keep the list structure. Bullets and numbers are not decoration. They tell the reader where one item ends and the next begins, and without them a five-item list becomes one long sentence.

Tables deserve the same treatment. A row of cells joined with tabs keeps the columns readable, while cells joined with nothing turn "Price 49.99" into "Price49.99".

When you actually need this

This comes up more often than people expect. Cleaning up HTML email templates before pasting them into a plain-text field. Pulling the readable text out of a saved web page for a search index. Turning a Word export full of markup into something you can paste into a form. Preparing page content for an LLM prompt, where every stray tag is wasted tokens. Checking what a screen reader or a search engine actually sees when the styling is gone.

In every one of those cases, the goal is the same: the words, in the right order, with the structure a human reader needs and nothing else.

I built a free HTML to text converter that does exactly this, using the browser parser approach above. It keeps paragraphs, lists and tables readable, decodes entities properly, strips scripts and styles, and lets you choose whether link URLs and image alt text survive. It also takes a file upload and gives you a clean .txt download. It runs entirely in your browser, and you can try it here: HTML to Text Converter.

Your HTML is not text with angle brackets sprinkled on it. It is a document. Let a parser read it.

The minifier that ate your spaces: why HTML minifying is harder than it looks

Mubeen Khan — Wed, 11 Nov 2026 10:45:38 +0000

Minifying CSS is easy. Minifying JavaScript is a solved problem. Minifying HTML looks easy too, until the day your minifier eats a space that mattered and two words glue themselves together on the live page.

Here is the trap. In HTML, whitespace is not decoration. It is content.

The space between two words is load-bearing

Take this markup:

<p>Click <a href="/pricing">here</a> to see the price.</p>

There is a space after "Click" and a space before "to". A careless minifier sees whitespace between tags and deletes it, because most whitespace in HTML is meaningless. But these two spaces are the only thing keeping "Click", "here" and "to see the price" as separate words. Strip them and your page reads "Clickhere to see the price." or worse, "Clickhereto see the price."

The same rule applies everywhere inline elements touch text: <strong>, <em>, <span>, <a>, <code>. A minifier that treats HTML like a flat string will break your sentences. A correct minifier has to understand the document: it must know which elements are inline, which are block-level, and where a space is a word separator rather than formatting.

The elements a minifier must never touch

Whitespace is not the only landmine. Three elements carry content where every single character matters:

<pre> — the whole point of a preformatted block is that spaces and line breaks are preserved. Minify inside one and your code sample collapses into a single unreadable line.

<textarea> — the default text inside a textarea is user-visible content. Strip its leading newline and the first line of your form shifts.

<script> and <style> — these contain other languages. A space inside a JavaScript string literal is data, not formatting. An HTML minifier that rewrites script contents is a bug waiting to happen. The right move is to leave these blocks byte-for-byte alone and let a dedicated JS or CSS minifier handle them.

Conditional comments () are another one. They look like comments, but old versions of Internet Explorer treat them as instructions. Delete them and you change behavior for the exact users they were written for.

What a good HTML minifier actually removes

Once the protected zones are fenced off, the safe savings are real:

Comments that carry no instructions (regular  comments).
Whitespace between block-level elements, where it never renders. The newline between </div> and <div> is invisible to every browser.
Optional end tags. HTML allows you to drop </p>, </li>, </td> and a few others, because the parser infers them. Removing them is valid, but only when the next tag makes the boundary unambiguous.
Quotes around attribute values, but only when the value contains no spaces or special characters. class=button is fine. class=big button is not, and must keep its quotes.
Boolean attributes. disabled="disabled" can become just disabled. Same meaning, fewer bytes.

On a typical hand-written page these add up to 20 to 40 percent smaller HTML. On a page generated by a framework with generous indentation, it can be more.

The test every minifier should pass

Before trusting any HTML minifier with your production markup, run one check: minify a page, then beautify it again, then minify it a second time. The two minified outputs should be identical. If they are not, the tool is making decisions that depend on formatting rather than structure, and it will eventually make a wrong one.

The other check is simpler: paste in a paragraph with a link in the middle of a sentence, minify it, and read the sentence back. If the words are still separate, the tool understands HTML. If they glued together, it is a string replacer wearing a minifier costume.

I built a free HTML minifier that passes both checks. It uses a tag-aware scanner, so inline word spaces survive, pre, textarea, script and style contents are preserved verbatim, conditional comments and the doctype stay put, and you get five toggles for exactly how aggressive it should be. It also beautifies, so you can round-trip your markup and confirm the output is stable. It runs entirely in your browser, and you can try it here: HTML Minifier.

Your HTML is probably 30 percent whitespace. The trick is removing the 30 percent that does nothing while keeping the spaces that are actually words.

Your minifier did not break your code. The missing semicolon did.

Mubeen Khan — Tue, 10 Nov 2026 10:34:41 +0000

Minification gets blamed for a lot of bugs it never caused. A script works fine in development, you run it through a minifier, and suddenly it throws in production. The minifier must have mangled something, right?

Most of the time, no. The minifier just removed the whitespace that was secretly holding your code together. The real culprit is automatic semicolon insertion, and it was already in your code, waiting.

The newline that was doing real work

JavaScript inserts semicolons for you when it thinks a statement has ended. That is convenient right up until a newline is the only thing separating two statements that should not be joined.

Take this:

const total = price + tax
(total > 100 ? applyDiscount() : checkout())

With the newline in place, JavaScript reads two statements. Now minify it by joining the lines:

const total = price + tax(total > 100 ? applyDiscount() : checkout())

That is one statement now, and it calls tax as a function. tax is a number, so you get tax is not a function in production, on a line that looks nothing like your source.

A good minifier knows this and keeps a newline or a semicolon where ASI matters. A naive whitespace stripper does not, and this is the exact bug that makes people say "minifiers are unsafe."

What a minifier actually removes

A real minifier does three jobs, in order of how much they save:

Comments and whitespace. The biggest, safest win. Nothing about how the code runs changes.
Shortening names. Local variables like shoppingCartTotal become t. Top-level names are usually left alone, because another script might use them.
Rewriting expressions. if (false) { ... } disappears. true becomes !0. const x = 1 + 2 becomes const x = 3. This is the part that needs a real parser, because it has to prove the rewrite is safe before doing it.

That third job is why a parser-based minifier (Terser is the one behind webpack and Vite) beats a text-based one. A text tool can only guess where a string ends and a comment begins. A parser knows.

What minification is not

Minification is not obfuscation, and it is not security. Anyone can run your minified file through a formatter and get readable code back in seconds. If the code contains a secret, minifying it does not hide the secret. It only makes the file smaller.

It is also not a substitute for a bundler. If your project has a build step, let the bundler minify. An online minifier is for the one-off jobs: a tag manager snippet, a CMS embed, a bookmarklet, a quick check of how small a script can get.

The habit that prevents the whole class of bugs

Write semicolons, or use a formatter that inserts them. That is the entire fix. If every statement ends with an explicit semicolon, no minifier can ever join two statements by accident, because there is nothing ambiguous left to join.

And before you ship a minified one-off script, paste it back into your browser console and run it once. Thirty seconds of checking beats a production error every time.

If you want to try it on your own code, this free JavaScript minifier runs entirely in your browser: JavaScript Minifier. Paste a script, toggle mangling and compression, and watch the byte count drop. Your code never leaves your device, and if it has a syntax error you get the parser's own message instead of broken output.

Your CSS is 30% whitespace. Here is what a minifier actually removes

Mubeen Khan — Mon, 09 Nov 2026 10:51:18 +0000

Your stylesheet is bigger than it needs to be. Not because of your selectors or your design, but because of the parts a browser never reads: the comments, the indentation, the line breaks, the last semicolon in every rule, the px after every 0.

A CSS minifier strips exactly those things. Nothing else. The page renders identically, but the file is smaller, downloads sooner, and blocks rendering for less time. CSS is render-blocking, so a smaller stylesheet is one of the cheapest performance wins on the web.

What gets removed

Take a typical hand-written rule:

/* Main layout for the blog cards */
.card {
  display: flex;
  flex-direction: column;
  gap: 16px;
  padding: 24px 16px;
  margin: 0px auto;
  background-color: #ffffff;
}

Minified, it becomes:

.card{display:flex;flex-direction:column;gap:16px;padding:24px 16px;margin:0 auto;background-color:#fff}

Six things happened there. The comment is gone. The whitespace collapsed. The last semicolon dropped. #ffffff became #fff. 0px became 0. And the whole thing is one line. Most stylesheets shrink 15 to 40 percent this way, depending on how many comments and how much formatting the original has.

The one thing a minifier must never touch: calc()

There is a trap in naive minification, and it is calc(). This is valid CSS:

.card {
  width: calc(100% - 32px);
}

Remove the spaces around the minus and you get calc(100%-32px), which is invalid CSS. The browser throws the whole declaration away, and your layout silently breaks. A real minifier has to understand CSS, not just delete spaces: it keeps the spaces inside calc(), leaves quoted strings alone, and never mangles a url() value.

The same rule applies to content strings. If your stylesheet says content: "a b", those two spaces are part of the text on the page. A blind find-and-replace would eat them. A scanner that knows what a string is will not.

When to minify, and when to use a build tool

For a full project, a build tool like cssnano or Lightning CSS will save more: it understands source maps, merges duplicate rules, and folds into your pipeline. Use it there.

But most of the time you are not minifying a project. You are pasting one stylesheet from a theme, a snippet from a tutorial, or a chunk copied out of DevTools, and you want it smaller right now. That is the job for a paste-and-go minifier: no install, no config, no upload. Paste it in, copy the smaller version out, done.

I built one that does exactly this, with the calc() and string handling above, plus a beautify mode that turns a minified file back into indented, readable CSS when you inherit one and need to read it: CSS Minifier. It runs entirely in your browser, so your stylesheet never leaves your device, which matters when the CSS belongs to a client project.

The honest footnote

Minifying is the raw saving. Once your server applies gzip or Brotli, the transfer size shrinks again, so the percentage a minifier shows you is the before-compression number. The real win is smaller on the wire than on disk, but it is still real, and it costs you nothing: the file is smaller at every step from here on.

So before your next deploy, run your stylesheet through a minifier once. If it comes back 30 percent smaller, that was 30 percent of your CSS doing nothing but taking up space.

Your Kubernetes manifest is YAML. Your API wants JSON. Here is the conversion, done right

Mubeen Khan — Sun, 08 Nov 2026 10:32:38 +0000

Your Kubernetes manifest is YAML. Your API wants JSON. Here is the conversion, done right

Every developer who has touched Kubernetes, Docker Compose, or a GitHub Actions workflow has hit the same small wall. The config lives in YAML. The tool that needs to consume it, validate it, or pipe it through jq only speaks JSON. So you convert it. And the conversion is where quiet bugs are born.

YAML is not JSON with nicer formatting

It looks like it. Both describe nested maps and lists. But YAML has opinions JSON does not. A bare yes is a boolean in YAML 1.1 and a string in YAML 1.2. on and off have the same split personality. A timestamp like 2026-11-08 can silently become a date object in one parser and stay a string in another. Anchors (&defaults) and aliases (*defaults) let one block appear in five places, and merge keys (<<) fold shared config into a service definition. None of that exists in JSON, so a converter has to decide what each of those becomes, and a careless one decides wrong without telling you.

The classic failure looks like this. A Docker Compose file defines a shared logging block once with an anchor, then reuses it in three services. Someone pastes it into a converter that drops anchors instead of expanding them. The JSON comes out clean, valid, and wrong: three services with no logging config at all. Nothing errors. The deploy goes out, and the missing logs are discovered at 2am, during an incident, when logs are the one thing you need.

What a good conversion actually does

First, it expands anchors and merge keys into full copies, so every place that referenced a block gets the complete block. Second, it tells you which YAML version its typing follows, because enabled: yes becoming true or "yes" changes what your application does. Third, it handles multi-document files. A Kubernetes manifest is often three documents separated by --- in one file, and the honest JSON for that is an array with one entry per document, not a silent merge that drops two of them. Fourth, it reports errors with a line and column, because "invalid YAML" without a location is not an error message, it is a shrug.

The reverse direction matters just as much. JSON to YAML should produce readable block style, not a wall of flow syntax, because the YAML you get back is usually going into a file a human will edit next.

The privacy part nobody thinks about until it is too late

YAML files are where secrets hide in plain sight. A Compose file holds registry credentials. A Helm values file holds tuned internal hostnames. A GitHub Actions workflow embeds environment names and deployment logic. Pasting any of that into a server-side converter sends your infrastructure's address book to a stranger's server. A converter that runs entirely in your browser never uploads anything, and that is not a marketing line, it is the only safe way to handle config files.

I built a free converter that does all of this in the browser: YAML to JSON and back, multi-document files become a JSON array, anchors expand properly, errors come with exact line numbers, and nothing ever leaves your device. It is at YAML to JSON Converter. Try it with a real Compose file, then check the JSON against what you expected, especially any anchors. If the output surprises you, the surprise was in your YAML all along, and now you know before production tells you.

Your API returned one giant line of XML. Here is how to read it

Mubeen Khan — Sat, 07 Nov 2026 10:30:45 +0000

You call an endpoint, you get a response, and it is one enormous line of XML. No line breaks. No indentation. Just a wall of angle brackets that your eyes slide straight off.

You could paste it into your editor and hope the formatter plugin is installed. You could squint at it in the terminal. Or you could format it in about two seconds, in the browser, without uploading it anywhere.

Why XML arrives as one line

Minified XML is not broken. APIs and export tools strip whitespace on purpose, because whitespace costs bytes and machines do not care about readability. The document is perfectly valid. It is just unreadable to a human.

The fix is mechanical: re-indent every element by its nesting depth. An opening tag pushes the next line one level deeper. A closing tag pulls it back. Text content stays on its own line. That is the whole trick, and any tool that does it well is worth keeping bookmarked.

Format it in the browser, privately

The fastest route is a formatter that runs entirely in your browser. Paste the blob, pick an indent (two spaces is the usual default, four if your team prefers it), and you get a readable document back. No upload means the XML never leaves your machine, which matters when the payload contains internal endpoints, customer records, or production config.

I built one for exactly this job: a free XML formatter and validator that pretty-prints, minifies, validates, and converts XML to JSON, all client-side. It flags malformed XML with the exact line and column of the problem instead of a vague "parse error", and it refuses DOCTYPE declarations and external entities, so pasting untrusted XML cannot trigger an XXE-style surprise. Try it here: https://www.theutilityhub.online/tools/xml-formatter

The errors you will actually see

Most malformed XML is one of three mistakes:

Mismatched tags. <user><name>Alex</user></name> closes the tags in the wrong order. XML is strict about nesting, unlike HTML, which forgives it.
Unclosed tags. One <item> never gets its </item>, usually after a copy-paste.
A second root element. XML allows exactly one root. Two top-level elements is not a document, it is two documents glued together.

A good validator points at the line and column. A bad one just says "invalid". When you are debugging a 200KB response, that difference is the whole job.

Minify, and XML to JSON

Formatting is only half the tool. Minify does the reverse: it strips the whitespace back out when you need the smallest possible payload to paste into a test or a config field. And XML to JSON conversion is handy when the rest of your pipeline speaks JSON and you want the data, not the markup.

One habit makes all of this painless: never debug raw XML. Format first, read second. The bug is almost always visible the moment the nesting is correct.

The five characters that break your HTML (and the one habit that fixes them)

Mubeen Khan — Fri, 06 Nov 2026 10:31:50 +0000

You have done this. You paste a code snippet into a blog post, a comment box, or a CMS field, hit save, and half of it vanishes. The <div> you typed is gone. The & in "Tom & Jerry" turned into something weird. A <script> tag someone typed into a form actually ran.

It is not a bug in your editor. It is HTML doing exactly what it was designed to do: angle brackets mean "a tag starts here", and ampersands mean "an entity starts here". When you want those characters to show up as plain text, you have to tell the browser so, by writing them as HTML entities.

The five characters that matter

Almost every encoding problem comes down to five characters:

& becomes &
< becomes <
> becomes >
" becomes "
' becomes '

That is the whole list for safe output. Encode those five and your text displays exactly as typed, in every browser, with no surprises. Everything else, accented letters, currency symbols, emoji, can stay as plain UTF-8 text in a modern page.

Why this is a security habit, not a formatting trick

Encoding is the same operation that stops cross-site scripting. When a comment, a username, or a search box value is printed into a page without encoding, a stranger's <script> tag becomes your page's script tag. The OWASP XSS Prevention Cheat Sheet puts it plainly: encode untrusted data at output time, in the HTML body context, every time.

The rule is "encode once, at output". Encoding twice is the classic self-inflicted bug: & encoded again becomes &amp; and your readers see raw codes on the page. If your output shows literal & text, you almost certainly encoded something that was already encoded.

The three forms an entity can take

Entities come in three flavours, and a good decoder handles all of them:

They are interchangeable to the browser. Named entities are the readable choice when a human will read the source; numeric entities are the fallback for characters with no named form. Decoding has to recognise all three, including mixed content where a string contains named and numeric entities side by side.

When named entities actually help

For everyday content, minimal encoding (the five characters) plus UTF-8 is the right default. Named entities earn their keep in three spots:   when two words must never split across a line, — and – when you want real dashes without worrying about keyboard layouts, and © ® ™ in footers and legal lines where the symbol has to survive copy-paste through systems that mangle UTF-8.

A quick way to check your own output: paste a snippet containing <, >, & and a quote into a free HTML entities encoder and decoder, encode it, and read the result. If the output is readable and every special character turned into an entity, your mental model is right. I built one for exactly this check, it runs entirely in your browser and never uploads your text: https://www.theutilityhub.online/tools/html-entities-encoder-decoder

The habit to keep

Encode at output, decode at input, never twice, and never trust raw text from a user into a page. It is five characters and one rule, and it removes an entire class of bugs, from vanishing code snippets to stored XSS, in one move.

Your brand has one color. The color wheel knows the other four.

Mubeen Khan — Thu, 05 Nov 2026 10:30:23 +0000

Every designer has been here. You have one good brand color, maybe a blue you love, and now you need four more that go with it. So you open a color picker, guess a lighter blue, guess a pink that might work, and twenty minutes later your palette looks like five strangers at a bus stop.

That guessing is the problem. Color harmony is not taste, it is math, and the color wheel has done the work for you for about three hundred years.

The wheel is a calculator

A color is really three numbers: hue (where it sits on the wheel, 0 to 360), saturation (how vivid it is) and lightness (how bright). Harmony rules are just recipes for picking hues at fixed distances from your base color.

Complementary: your color plus the one exactly opposite it on the wheel, 180 degrees away. Blue and orange, purple and yellow. High contrast, high energy, and the reason every "50 percent off" banner you have ever seen is orange on blue. Use it for accents and calls to action, never for two big areas side by side, or the page starts vibrating.

Analogous: your color plus its two neighbors, 30 degrees on either side. Blue, blue-green and green. Calm, natural, almost impossible to get wrong. This is the palette of dashboards and documentation sites, the ones that feel quiet and professional without trying.

Triadic: three colors evenly spaced, 120 degrees apart. Bold and balanced at the same time, which is why it shows up in branding for kids products, games and anything that needs to feel fun without feeling random. The trick is letting one color dominate and using the other two sparingly.

Split-complementary: your color plus the two colors next to its opposite. You get almost the punch of complementary without the vibration. It is the safe version of the loudest rule, and it is the one I reach for most.

Tetradic: two complementary pairs, a rectangle on the wheel. Four colors is a lot, so this one needs discipline: one dominant color, the rest as support. Get it right and a site feels rich; get it wrong and it feels like a carnival.

Monochromatic: one hue, different lightnesses. The easiest palette that always works. A dark navy, a mid blue, a pale sky blue, and you have a complete UI with zero risk. Boring is a feature when the content needs to do the talking.

The mistake everyone makes with tints

Pick a palette from a generator and the first thing people do is lighten a color by mixing it with white in RGB. That is how you get washed out pastels that look tired. Lighten in HSL space instead: keep the hue and saturation, raise the lightness. The color stays itself, just brighter. The same applies to darkening, which is how you get deep, rich shades instead of muddy ones.

The second mistake is contrast. A beautiful palette is useless if nobody can read the text on it. The rule is simple and checkable: body text needs a contrast ratio of at least 4.5 to 1 against its background, large text 3 to 1. You can compute this exactly from the two colors, so there is no reason to guess. If your light grey text fails on your light blue background, darken the text or darken the background until the number passes.

The workflow that saves the twenty minutes

You do not need to memorize the wheel. Pick your base color, pick a rule, and let the math build the palette: https://www.theutilityhub.online/tools/color-palette-generator

The generator I built gives you all six harmony rules from one base color, lets you lock the swatches you like and regenerate the rest, checks the WCAG contrast ratio for any text and background pair, and exports the finished palette as CSS variables, a Tailwind config or JSON. Copy the variables into your stylesheet and the palette is live in your project.

One habit worth stealing: export the palette as CSS variables on day one, before you write a single component. --color-primary, --color-accent, --color-surface, --color-text. When the brand color changes later, and it will, you change one line instead of hunting hex codes through fifty files.

Your brand color was never the hard part. The wheel already knew the other four. Let it tell you.

Your CSS gradient has a muddy middle, and it is not your fault

Mubeen Khan — Wed, 04 Nov 2026 10:29:47 +0000

A two color gradient should be simple. You pick a blue and a pink, you write one line of CSS, and the middle comes out grey. Not blue-pink. Grey. Muddy, washed out grey, like someone mixed all the paint together.

That grey middle is not a bug in your code. It is how RGB interpolation works, and once you see it you cannot unsee it.

What the browser actually does

background: linear-gradient(90deg, #2563eb 0%, #ec4899 100%) tells the browser to walk from blue to pink. In RGB space that walk passes through the average of the two colors, and the average of a saturated blue and a saturated pink is a desaturated mauve-grey. The browser did exactly what you asked. You just asked in the wrong color space.

Three fixes, in order of effort:

1. Add a middle stop. Put a vivid color at 50 percent and the gradient has to pass through it. #2563eb 0%, #8b5cf6 50%, #ec4899 100% never goes grey because the midpoint is a real purple, not an average. This is the fastest fix and it works everywhere.

2. Use more stops, closer together. A gradient with stops at 0, 25, 50, 75 and 100 percent gives you control over the whole journey instead of letting the browser improvise the middle. Hard stops, two stops at the same percentage, give you a clean split instead of a blend, which is how striped and two-tone backgrounds are made.

3. Change the interpolation space. Modern CSS lets you write linear-gradient(in oklch, #2563eb, #ec4899), and OKLCH walks through vivid colors instead of grey. It looks dramatically better. The catch is older browsers: keep a plain RGB gradient line above it as a fallback, and browsers that understand the new syntax will use the better one.

Angle and shape matter more than color

Most gradients people dislike are not bad colors, they are bad geometry. A 90 degree gradient across a wide hero banner stretches the blend so thin that most of the banner is one flat color. A 135 degree diagonal keeps the blend visible. A radial gradient centered on the content draws the eye inward, which is why it works for cards and modals. A conic gradient starting at the top spins color around a point, which is great for pie charts and progress rings and terrible for backgrounds.

Pick the type for the job: linear for banners and buttons, radial for spotlights and cards, conic for rings and charts.

The workflow that saves time

Write gradients by hand and you will spend twenty minutes tweaking percentages and reloading. Use a visual builder instead: pick the type, drag the stops, set the angle, and copy the finished CSS. I built one that also gives you the Tailwind class and a PNG or SVG export for when the design needs an image instead of code: https://www.theutilityhub.online/tools/css-gradient-generator

One more habit worth stealing: never ship a gradient without a fallback background color. Put background-color with your first stop color on the line above the gradient. If anything fails, the page still shows a sensible solid color instead of white.

The grey middle was never your taste failing. It was RGB interpolation doing its job. Give it a middle stop or a better color space, and the gradient you imagined is the one that shows up.