DEV Community: Simran Kaur

How to Check a Page's Canonical URL Programmatically (Node.js)

Simran Kaur — Tue, 08 Sep 2026 11:05:11 +0000

Canonical bugs are the quiet kind. The page looks fine, it ranks for a while, and then a theme change or a new plugin points rel="canonical" at the wrong URL. Google follows the tag, consolidates the wrong version, and your traffic slides. No error, no 404, nothing in the logs.

If you build or maintain sites, you can catch this in code. Here is how to read a page's canonical URL in Node, classify what it means, check many pages at once, and even test IP canonicalization.

Where canonical URLs actually live

Most people check the HTML. There are really two places a canonical can be declared, and a good check reads both:

The HTML <link rel="canonical" href="..."> in the <head>.
The HTTP Link response header: Link: <https://example.com/>; rel="canonical".

That header version is easy to forget. It is common on PDFs and non-HTML resources, and some CDNs and frameworks set it. If the header and the HTML disagree, search engines can get conflicting signals, so you want to catch that too.

Reading the canonical in Node

Node 18+ ships a global fetch, so no dependencies are needed for a basic check:

async function getCanonical(url) {
  const res = await fetch(url, {
    redirect: "follow",
    headers: { "User-Agent": "canonical-check/1.0" },
  });

  let canonical = null;
  let source = null;

  // 1) HTTP Link header
  const linkHeader = res.headers.get("link");
  if (linkHeader) {
    const m = linkHeader.match(/<([^>]+)>\s*;\s*rel=["']?canonical["']?/i);
    if (m) {
      canonical = m[1];
      source = "http-header";
    }
  }

  // 2) HTML <link rel="canonical">
  if (!canonical) {
    const html = await res.text();
    const tag = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
    if (tag) {
      const href = tag[0].match(/href=["']([^"']+)["']/i);
      if (href) {
        canonical = href[1];
        source = "html";
      }
    }
  }

  return { requested: res.url, canonical, source };
}

For production I would reach for cheerio to parse the HTML instead of a regex, since regex on HTML breaks on edge cases. But for a quick audit script, the pattern above is enough.

Classifying what the canonical means

Finding the tag is half the job. The useful part is what it tells you:

function classify(requested, canonical) {
  if (!canonical) return "missing";
  const norm = (u) => u.replace(/\/+$/, "").toLowerCase();
  return norm(canonical) === norm(requested)
    ? "self-referencing" // the healthy default
    : "points-elsewhere"; // intentional for duplicates, a bug otherwise
}

self-referencing: the page points to itself. This is what you want on a normal, unique page.
points-elsewhere: fine for a duplicate or a paginated page consolidating to page one, a problem when it is accidental.
missing: search engines pick their own preferred version, which is a coin flip you do not want to leave to chance.

Put together:

const { requested, canonical, source } = await getCanonical("https://example.com/");
console.log(classify(requested, canonical), canonical, `(${source ?? "none"})`);

Bulk-checking a whole site

One page is never the real job. After a migration you want to scan a list:

const urls = [
  "https://example.com/",
  "https://example.com/blog/",
  "https://example.com/pricing/",
];

for (const url of urls) {
  try {
    const { requested, canonical } = await getCanonical(url);
    console.log(`${classify(requested, canonical).padEnd(16)} ${url} -> ${canonical ?? "MISSING"}`);
  } catch (e) {
    console.log(`error            ${url} -> ${e.message}`);
  }
}

Feed it your sitemap URLs and you have a canonical audit in a few seconds. Add a small concurrency limit if the list is long so you do not hammer the server.

The one people miss: IP canonicalization

Here is a subtle one. If your server answers on its raw IP address as well as your domain, search engines can index both http://203.0.113.10/ and https://example.com/ as separate sites. That splits link equity for content that is literally identical.

The test: resolve the domain to its IP, request the IP directly, and check whether it redirects back to the domain.

import dns from "node:dns/promises";

const host = "example.com";
const { address: ip } = await dns.lookup(host);

const res = await fetch(`http://${ip}/`, { redirect: "manual" });
const location = res.headers.get("location") || "";

if ([301, 302, 307, 308].includes(res.status) && location.includes(host)) {
  console.log("PASS: the IP redirects to your domain");
} else if (res.status >= 200 && res.status < 300) {
  console.log("FAIL: the IP serves content directly (duplicate content risk)");
} else {
  console.log("Blocked or no response, which usually means no IP duplicate content");
}

Note that on shared hosting the IP often belongs to many sites, so this test is most meaningful on a dedicated IP or behind your own reverse proxy.

When you just need an answer, not a script

For a one-off check, or to hand to someone who does not write Node, a browser tool is faster. I built a free one that does all of the above: Pixellize Canonical URL Checker. It reads both the HTML tag and the HTTP Link header, flags self-referencing vs points-elsewhere vs missing, has a bulk mode for up to 20 URLs with CSV export, and an IP canonicalization test. It runs in the browser, nothing is uploaded.

If you want the non-code background on canonicals, these two guides go deeper: how to find the canonical URL of any website and how to change a canonical URL.

Takeaways

Canonicals live in two places: the HTML <link> and the HTTP Link header. Check both, and flag conflicts.
In Node, fetch plus a small parser is enough to read and classify canonicals.
Bulk-scan your sitemap after every migration or theme change, since that is when canonicals silently break.
Do not forget IP canonicalization if you run your own server or reverse proxy.

How do you audit canonicals in your stack? Let me know in the comments.

Convert CSV to Excel (XLSX) in JavaScript, in the Browser and in Node

Simran Kaur — Tue, 08 Sep 2026 10:20:35 +0000

You export a CSV, someone opens it in Excel, and 00123 turns into 123. A phone column becomes scientific notation. Dates flip from day-month to month-day depending on the machine's locale. If you have ever shipped a "data export" feature, you have gotten that bug report.

The root cause is simple: a CSV is plain text with no type information. When Excel opens it, it guesses what each column is. A real .xlsx file stores the type per cell, so once you write XLSX yourself you get to decide, and the guessing stops.

Here is how to convert CSV to Excel in JavaScript, both server-side in Node and fully in the browser, without losing your data along the way.

The one-liner that works for clean data

If your data is genuinely simple (no IDs with leading zeros, no long numbers, no ambiguous dates), the fastest path uses the xlsx package:

npm install xlsx

const XLSX = require("xlsx");

// read the CSV straight into a workbook
const workbook = XLSX.readFile("employees.csv");

// write it back out as a real .xlsx
XLSX.writeFile(workbook, "employees.xlsx");

Two lines of real work. readFile parses the CSV into a sheet, writeFile serializes it to XLSX. Done.

The catch: readFile still lets the parser coerce values. 00123 can still come out as the number 123. So for anything that matters, keep reading.

Keeping leading zeros, long numbers, and dates intact

The fix is to read the CSV as raw strings, then force the fragile columns to the text type before you write. Here is a version that treats an Employee ID column as text so zeros survive:

const XLSX = require("xlsx");
const fs = require("fs");

const csv = fs.readFileSync("employees.csv", "utf8");

// parse as strings, do not let the parser guess types
const workbook = XLSX.read(csv, { type: "string", raw: true });
const sheet = workbook.Sheets[workbook.SheetNames[0]];

// walk the cells and pin column A (Employee ID) to text
const range = XLSX.utils.decode_range(sheet["!ref"]);
for (let row = range.s.r + 1; row <= range.e.r; row++) {
  const addr = XLSX.utils.encode_cell({ r: row, c: 0 }); // column A
  const cell = sheet[addr];
  if (cell) {
    cell.t = "s";                 // s = string
    cell.v = String(cell.v);      // keep the original text, zeros and all
  }
}

XLSX.writeFile(workbook, "employees.xlsx");

cell.t = "s" is the whole trick. It tells the XLSX writer "this is text, not a number," so Excel shows 00123 exactly as written instead of helpfully stripping the zeros.

The same idea covers the other classic breakages:

Long IDs (16+ digits): set them to text, or Excel renders 1.2E+15.
Dates: either keep them as text in a known format like YYYY-MM-DD, or write real date cells with cell.t = "d" and a cell.z number format so every machine reads them the same way.
Encoding: read the file as UTF-8 (as above) so accented names like Muller do not turn into symbols.

Doing it entirely in the browser

You do not need a server for this. The same library runs client-side, so the file never leaves the user's machine, which is the right call for anything private like a customer list.

<input type="file" id="file" accept=".csv" />
<script src="https://cdn.jsdelivr.net/npm/xlsx/dist/xlsx.full.min.js"></script>
<script>
document.getElementById("file").addEventListener("change", async (e) => {
  const file = e.target.files[0];
  const text = await file.text();

  // parse the CSV as strings so nothing gets coerced
  const wb = XLSX.read(text, { type: "string", raw: true });

  // hand the user a real .xlsx download
  XLSX.writeFile(wb, file.name.replace(/\.csv$/i, "") + ".xlsx");
});
</script>

file.text() reads the CSV, XLSX.read parses it, and writeFile in the browser triggers a download of the generated workbook. No backend, no upload, no temp files to clean up.

Batch converting a folder in Node

When you have a directory of CSVs to convert on a schedule, loop over them:

const XLSX = require("xlsx");
const fs = require("fs");
const path = require("path");

const dir = "./exports";
for (const name of fs.readdirSync(dir).filter((f) => f.endsWith(".csv"))) {
  const wb = XLSX.readFile(path.join(dir, name));
  XLSX.writeFile(wb, path.join(dir, name.replace(/\.csv$/i, ".xlsx")));
}

Drop this in a cron job or a CI step and your CSV drops become XLSX automatically.

When you just need it once, without writing code

Not every CSV-to-Excel job deserves a script. If you are handing the task to a non-developer, or you just need a clean workbook once, a browser tool is faster than wiring up a project.

I built a free one for exactly this: Pixellize CSV to XLSX converter. Drop a .csv, review the parsed grid (it keeps leading zeros), edit any cell, and download a real .xlsx. It runs fully in the browser, so nothing is uploaded. There is also an XLSX to CSV converter and an Excel to JSON tool for the reverse trips.

If you want the non-code walkthrough with screenshots and the Excel-specific gotchas, I wrote that up here: How to convert CSV to Excel without breaking your data.

Takeaways

A CSV has no type information, so opening it in Excel means letting Excel guess. Writing XLSX yourself removes the guessing.
In JavaScript, XLSX.read plus XLSX.writeFile does the conversion in two steps, in Node or in the browser.
Read values as strings and set cell.t = "s" on fragile columns to keep leading zeros and long numbers.
Handle dates explicitly and read as UTF-8 so nothing silently changes.

Got a favorite approach for typed CSV imports? Drop it in the comments.

How to Detect What WordPress Theme (and Stack) a Website Uses

Simran Kaur — Thu, 03 Sep 2026 07:23:48 +0000

You land on a slick website and wonder: is this WordPress, and if so, what theme is it running? You can usually answer both in under a minute by reading a few signals the site leaves in its HTML and a couple of predictable endpoints. Here is how to do it by hand, and how to script it.

The five signals that give WordPress away

WordPress leaves fingerprints. Any one of these is a strong hint; two or more is near certainty.

Asset paths contain /wp-content/ or /wp-includes/
A login page exists at /wp-login.php (and /wp-admin/ redirects to it)
The generator meta tag: <meta name="generator" content="WordPress 6.x">
The REST API responds at /wp-json/
The theme path: styles load from /wp-content/themes/<theme-name>/

That last one is the good part. The folder name after /themes/ is usually the theme slug.

Checking by hand

Open the page source (Ctrl+U) and search for wp-content. If it is there, it is almost certainly WordPress. Then search for /themes/ to read the theme slug:

https://example.com/wp-content/themes/astra/style.css
                                    ^^^^^ theme slug

Hit /wp-json/ in the address bar. A JSON response with name, description, and routes confirms WordPress and often leaks the site title and active plugins via the REST routes.

Scripting it

Here is a minimal Node check that fetches the HTML and reports the signals:

async function detectWordPress(url) {
  const html = await fetch(url).then(r => r.text());

  const isWP =
    /wp-content|wp-includes/.test(html) ||
    /<meta name="generator" content="WordPress/i.test(html);

  const theme = html.match(/\/wp-content\/themes\/([^\/'"]+)/)?.[1] ?? null;

  const generator = html.match(
    /<meta name="generator" content="(WordPress[^"]*)"/i
  )?.[1] ?? null;

  return { url, isWP, theme, generator };
}

detectWordPress("https://example.com").then(console.log);
// { url: "...", isWP: true, theme: "astra", generator: "WordPress 6.6" }

For plugins, scan asset URLs for /wp-content/plugins/<plugin-slug>/. Each unique slug is a plugin loading a script or stylesheet on the front end.

const plugins = [...html.matchAll(/\/wp-content\/plugins\/([^\/'"]+)/g)]
  .map(m => m[1]);
console.log([...new Set(plugins)]);

Why detection sometimes fails

It is not foolproof, and it is worth knowing the blind spots:

Headless WordPress: the front end is React or Next.js, so wp-content never appears. The /wp-json/ endpoint may still respond.
Security plugins rename the login URL and strip the generator tag.
Aggressive caching/optimization can rewrite or inline asset paths, hiding theme folders.
CDNs sometimes serve assets from a different host, so match the path, not the domain.

So treat a negative result as "probably not, but check /wp-json/ before you are sure."

When you just want the answer

If you do not want to open a console, paste the URL into the WordPress Theme Detector on Pixellize. It runs these same checks and returns the theme name, version, author, and detectable plugins in one view. It is the scripted logic above with a UI, and it is free.

Wrap up

WordPress is one of the easiest platforms to fingerprint: wp-content in the source, a /wp-login.php page, the generator tag, and a live /wp-json/ endpoint. Read the /themes/<slug>/ path for the theme and /plugins/<slug>/ for plugins. Script it for bulk checks, or run a single URL through the detector when you just need a fast answer.

Meta Title and Description Length: What Google Actually Cuts Off

Simran Kaur — Tue, 01 Sep 2026 07:15:27 +0000

You ship a page, Google indexes it, and then your title shows up cut off with an ellipsis in the search results. Or worse, your carefully written meta description gets replaced entirely. Most of the time the cause is boring: the title or description was the wrong length.

Here is what actually gets truncated, the numbers that matter, and how to check any page in a few seconds.

Why length matters at all

Google gives each search result a fixed amount of room. Go over it and the end of your title or description gets chopped with an ellipsis, which usually means your call to action or keyword never gets seen. Under-use it and you waste space that could have earned the click.

Two elements you control:

Title tag (<title>): the blue clickable headline
Meta description (<meta name="description">): the gray text under it

The numbers worth remembering

Google measures width in pixels, not characters, but characters are a reliable proxy for a quick check:

Element	Safe range	Gets cut around
Title tag	50 to 60 characters	~60 characters
Meta description	120 to 155 characters	~155 to 160 characters

Keep your primary keyword near the front of the title, because a truncated title still shows its beginning.

Reading them from the DOM

If you want to check the current page in the console:

const title = document.title;
const desc = document.querySelector('meta[name="description"]')?.content || "";

console.log("Title:", title.length, "chars");
console.log("Description:", desc.length, "chars");

const warn = (label, len, min, max) =>
  console.log(label, len < min ? "too short" : len > max ? "too long" : "good");

warn("Title", title.length, 50, 60);
warn("Description", desc.length, 120, 155);

That works for a page you are on. Checking a page you have already deployed is the more common need, and for that you have to fetch the HTML and parse the two tags out. Doing that from the browser hits CORS walls, so it usually needs a small server-side fetch.

The part people skip: the SERP preview

Length numbers tell you if something fits, but they do not show you what the result will actually look like. That matters because the same 58-character title reads very differently depending on the words. The only way to judge it is to see it rendered like a real Google result, on both desktop and mobile, since mobile truncates sooner.

A faster way to check

Rather than rebuild the fetch-and-parse step every time, I put it behind a UI: the Title and Meta Description Checker on Pixellize.

Paste any public URL and it pulls the live title and meta description, shows the character count against Google's ranges with color-coded bars, gives a quick 0 to 100 score, and renders a live SERP snippet preview for desktop and mobile. You can edit the title and description inline and watch the preview update, which is handy for testing rewrites before you push them. It runs free in the browser, and you can even copy a shareable link that reopens the exact check for a teammate.

The takeaway

Titles cut off near 60 characters, descriptions near 155, and Google measures pixels so treat those as guidelines, not hard rules. Check the length, then look at the actual snippet preview before you decide, because fitting the box and earning the click are two different things. Run one of your live pages through the checker and see how it looks.

How to Convert Text to Binary (and Back) in JavaScript

Simran Kaur — Sun, 30 Aug 2026 06:53:59 +0000

You type "Hi" and the computer stores 01001000 01101001. Text is just numbers wearing a costume. Here is exactly how a string turns into binary, why UTF-8 matters, and how to do the conversion both ways in a few lines of JavaScript.

What "binary" actually means here

Computers do not store letters. They store numbers, and every number is a run of ones and zeros. Each character maps to a code point, that number becomes a byte, and each byte is written as eight bits.

The letter A has the ASCII code 65. In binary that is:

65 = 01000001

Lowercase a is 97, which is 01100001. So the whole word "Hi" (H = 72, i = 105) becomes:

01001000 01101001

Group the bits into bytes of 8 and you can read any binary string back into text.

Text to binary in JavaScript

The reliable way is TextEncoder. It hands you the raw UTF-8 bytes, so you do not have to worry about character codes above 127.

function textToBinary(text) {
  const bytes = new TextEncoder().encode(text);
  return Array.from(bytes)
    .map(b => b.toString(2).padStart(8, "0"))
    .join(" ");
}

textToBinary("Hi"); // "01001000 01101001"

toString(2) gives the binary digits, and padStart(8, "0") keeps every byte a full 8 bits. Without the pad, H would come out as 1001000 (7 bits) and the string would be impossible to split back cleanly.

Binary back to text

Reverse the process: strip spaces, cut the string into 8-bit chunks, parse each chunk as a base-2 number, then decode the bytes with TextDecoder.

function binaryToText(bin) {
  const bits = bin.replace(/\s+/g, "");
  const bytes = new Uint8Array(bits.length / 8);
  for (let i = 0; i < bytes.length; i++) {
    bytes[i] = parseInt(bits.slice(i * 8, i * 8 + 8), 2);
  }
  return new TextDecoder("utf-8").decode(bytes);
}

binaryToText("01001000 01101001"); // "Hi"

Two checks worth adding in real code: reject anything that is not 0 or 1, and reject a bit count that is not a multiple of 8. Those two guards catch almost every bad paste.

The UTF-8 catch that trips people up

ASCII fits in one byte, so A is always 8 bits. But the moment you leave plain English, a character can take more than one byte.

textToBinary("é");  // "11000011 10101001"  (2 bytes)
textToBinary("🚀"); // 4 bytes, 32 bits

That is UTF-8 doing its job. If you assume one character equals one byte, accented letters and emoji will break your decoder. Using TextEncoder and TextDecoder handles this for you, which is why the manual charCodeAt approach you see in a lot of old tutorials quietly corrupts non-ASCII text.

When you just need the answer, not the code

If you are debugging, teaching, or solving a puzzle and you do not want to open a console, I built a free tool for this on Pixellize: the Text to Binary Translator. Paste text or binary, it converts both ways as you type, handles full Unicode, and runs entirely in your browser so nothing you paste is uploaded. It is the same logic above with a UI on top.

Wrap up

Text to binary is not magic, it is three steps: character to code point, code point to byte, byte to 8 bits. TextEncoder and TextDecoder give you the correct answer including emoji, and padding each byte to 8 bits is the detail that makes the round trip reversible. Try it in the console, or paste something into the Text to Binary Translator and watch it happen live.

How to Extract a .7z File Online Without Installing Anything

Simran Kaur — Wed, 26 Aug 2026 17:48:35 +0000

You download a file, it ends in .7z, and your computer just shrugs. Double-clicking does nothing useful. Windows has no built-in way to open it, and neither does macOS. So you go hunting for yet another app to install for a one-time job.

There is a faster way. You can open and extract a .7z archive straight in your browser, with no install and no upload.

What a .7z file actually is

.7z is a compressed archive format, like .zip, but it usually squeezes files smaller. That is why a lot of software, game mods, and large downloads ship as .7z. The tradeoff is support: .zip opens everywhere, .7z often does not.

The usual options, and why they are annoying

Install a desktop app. It works, but it is a full download and setup for something you might need once.
Use an online tool that uploads your file. Fast to start, but now your archive sits on someone else's server. For anything private, that is a real concern.

Extract a 7z file online, in your browser

The 7z Extractor on Pixellize runs entirely in your browser. Your file never leaves your device. Here is the whole flow:

Open the 7z Extractor.
Drop your .7z file onto the page, or click to pick it.
Browse the contents right there. You see every file and folder inside.
Pull out one file, or extract everything as a single .zip.

That is it. No account, no email, no install.

It handles the tricky cases too

Password-protected archives. If the .7z was made with a password, enter it and extract normally.
Nested folders. The file tree shows the full structure, so you grab exactly what you need instead of dumping everything.
Big archives. Since it runs locally, you are limited by your own machine, not an upload cap.

When a desktop app still makes sense

If you extract .7z files every day, or you script extraction as part of a build, a desktop tool like 7-Zip on Windows or The Unarchiver on Mac is the better fit. The online route wins for the common case: a one-off archive you just need to open right now, on any machine, without adding another installer.

Quick answers

Can I open a .7z file without 7-Zip?
Yes. A browser-based extractor opens .7z files with nothing installed. You browse the contents and pull files out directly.

Is it safe to extract 7z files online?
It depends on the tool. If the file uploads to a server, treat it like any upload. A tool that runs in your browser keeps the file on your device, which is safer for private archives.

What is the difference between .7z and .zip?
Both are compressed archives. .7z usually compresses smaller, but .zip opens on more devices without extra software.

Next time a .7z lands in your downloads, skip the installer. Open it in the browser, grab your files, and move on: try the 7z Extractor.

Saving a tweet as a PDF is harder than it looks (CORS, tokens, and Unicode)

Simran Kaur — Thu, 06 Aug 2026 04:50:15 +0000

I wanted a simple thing: paste a Twitter/X post link, get a clean PDF of it. Text, author, images, the whole card. No screenshots stitched together.

It sounded like a one-afternoon project. It was not. Here are the four walls I hit, and how I got past each one. If you ever try to read tweet data from the browser, this will save you a day.

Wall 1: you cannot read a tweet from the browser

The obvious first attempt: fetch the tweet from the syndication endpoint that X's own embed widgets use.

const id = "1719049883789729890";
const url = `https://cdn.syndication.twimg.com/tweet-result?id=${id}&lang=en&token=${token}`;
const res = await fetch(url); // TypeError: Failed to fetch

Dead on arrival. The response carries this header:

Access-Control-Allow-Origin: https://platform.twitter.com

So the endpoint only allows requests from X's own embed origin. No other website can call it from the browser, CORS blocks it. The old conversation endpoints (/timeline/conversation/<id>.json) now return 200 with an empty body, so those are gone too. And the official API needs a paid key.

There is no pure client-side path. If you want tweet data on your own site, something on your server has to fetch it.

The fix: a tiny server-side proxy

CORS is a browser rule. Server to server, it does not apply. So the browser asks my server, and my server asks X. My stack is WordPress, so this is a small REST endpoint (any backend works the same way).

register_rest_route('myplugin/v1', '/tweet', [
  'methods'  => 'GET',
  'permission_callback' => '__return_true',
  'callback' => function ($req) {
    $id    = preg_replace('/[^0-9]/', '', $req->get_param('id'));
    $token = preg_replace('/[^A-Za-z0-9]/', '', $req->get_param('token'));
    $url = "https://cdn.syndication.twimg.com/tweet-result?id=$id&lang=en&token=$token";

    $r = wp_remote_get($url, [
      'timeout' => 15,
      'headers' => ['User-Agent' => 'Mozilla/5.0 ... Chrome/124 Safari/537.36'],
    ]);
    // ...normalize and return JSON
  },
]);

One caveat worth knowing: send a real browser User-Agent. Without it the endpoint gets moody.

Wall 2: the mysterious `token`

That endpoint needs a token query param. It is not an API key. It is a value derived from the tweet ID, and X's own embed code computes it client-side. The formula floating around the web (used by Vercel's react-tweet) is:

function token(id) {
  return ((Number(id) / 1e15) * Math.PI)
    .toString(36)
    .replace(/(0+|\.)/g, "");
}

I compute this in the browser (it is trivial and exact there) and pass it to my endpoint, so the PHP side never has to reimplement JavaScript's float-to-base36. Clean division of labor.

Now the browser flow is:

const id = parseIdFromUrl(url);
const r  = await fetch(`/wp-json/myplugin/v1/tweet?id=${id}&token=${token(id)}`);
const post = await r.json(); // { name, handle, avatar, text, images, likes, replies, quoted }

Wall 3: images taint the canvas

To put images into a PDF, most tools rasterize through a <canvas>. But drawing a cross-origin image onto a canvas taints it, and toDataURL() throws a security error. Twitter's pbs.twimg.com sometimes cooperates with crossOrigin, sometimes not.

Simplest reliable fix: let the server fetch the image bytes too and hand them back as base64 data URLs. Data URLs are same-origin by definition, so no taint, ever.

$bin = wp_remote_retrieve_body(wp_remote_get($imgUrl, [...]));
$dataUrl = 'data:' . $mime . ';base64,' . base64_encode($bin);

Yes, base64 is about 33% bigger than the binary. For a handful of tweet images, who cares. It just works, on every browser, every time.

Wall 4: jsPDF breaks on Hindi and emoji

This one bit hardest. I drew the whole tweet card with jsPDF, which is great, until you feed it anything outside Latin-1. The built-in fonts (Helvetica and friends) have no glyphs for Devanagari, Arabic, CJK, or emoji. Hindi text came out as boxes and broken characters.

You can embed a full Unicode TTF, but a single font that covers every script plus color emoji is enormous and still incomplete.

The trick that actually works: render the text with the browser's canvas (which already has the system fonts for every script and emoji), then drop that as a crisp image into the PDF.

function textImage(text, maxWpt, fontPt, color) {
  const scale = 3;                    // render at 3x for sharp text
  const cv = document.createElement("canvas");
  const ctx = cv.getContext("2d");
  ctx.font = `${fontPt * scale}px Inter, "Noto Sans", "Noto Sans Devanagari", "Apple Color Emoji", sans-serif`;
  const lines = wrap(ctx, text, maxWpt * scale); // your own word-wrap
  cv.width = maxWpt * scale;
  cv.height = lines.length * fontPt * scale * 1.4;
  ctx.font = ...; ctx.fillStyle = color; ctx.textBaseline = "top";
  lines.forEach((l, i) => ctx.fillText(l, 0, i * fontPt * scale * 1.4));
  return { url: cv.toDataURL("image/png"), wPt: maxWpt, hPt: cv.height / scale };
}

// then in jsPDF:
doc.addImage(img.url, "PNG", x, y, img.wPt, img.hPt);

Tradeoff: that text is now an image, so it is not selectable. But it renders correctly in every language, which was the whole point. I keep the ASCII bits (handles, dates, counts) as real jsPDF text so those stay selectable.

Putting the card together

With data in hand, the layout is ordinary jsPDF drawing:

A centered card on a white page (no heavy border, just the content).
Circular avatar via a clip path (saveGraphicsState + circle + clip + addImage).
The verified badge is a blue filled circle with a white check drawn from two lines.
Images in a 2x2 grid, capped at 4 per page (that is Twitter's own max per post), with pagination when a thread runs long.
Quote tweets render as a nested bordered box, same building blocks, smaller.
A footer link using doc.textWithLink(...).

Engagement counts are worth a note: the public endpoint returns real favorite_count (likes) and conversation_count (replies), but not retweets or views. Rather than show a fake number or an empty dash, I only render the metrics that actually exist. Honest and cleaner.

Bonus: PNG export for free

Once the card renders nicely in the DOM (the on-page preview), exporting a shareable image is one library away. html2canvas snapshots the preview element, and because the images are already base64 data URLs, there is no CORS drama.

const canvas = await html2canvas(cardEl, { backgroundColor: "#fff", scale: 2, useCORS: true });
canvas.toBlob(blob => download(blob, "post.png"), "image/png");

Lessons

If a third party locks CORS to their own origin, no client-side trick beats it. Proxy through your server or stop.
Compute fiddly values (like that base36 token) on whichever side has the right primitives, then pass them along. Do not port float math across languages for no reason.
Base64 data URLs are the boring, reliable answer to canvas tainting.
jsPDF is Latin-only out of the box. For real i18n, render text on a canvas and embed it as an image.

The finished thing does what I wanted: paste a link, get a clean PDF or image, threads and quote tweets included, every language intact, all in the browser with a thin server helper.

If you want to see it in action: Twitter/X to PDF.

Have you fought the syndication endpoint or jsPDF's font limits before? I would love to hear how you handled it.

Convert Images to PDF in the Browser (No Upload, No Server)

Simran Kaur — Fri, 03 Jul 2026 07:13:07 +0000

You have five scanned pages sitting on your desktop and a form that only accepts a single PDF. So you search "images to PDF", pick the first result, and upload your documents to a server you know nothing about.

That last part should bother you more than it does.

Most free image-to-PDF converters send your files to their backend, run the conversion there, and hand you a download. For a meme, fine. For an ID, a payslip, or a signed contract, you just handed a stranger a copy. The good news: converting images to a PDF is a job the browser can do entirely on its own, no upload required. Here is how, both in code and with a tool.

Why do it client-side?

Bundling images into a PDF is pure client work. The browser can already decode a JPG or PNG, draw it to a canvas, and write the bytes of a PDF file. Nothing about that needs a server.

Doing it in the browser buys you three things:

Privacy. The file never leaves the device. No upload, no server logs, no retention policy to trust.
Speed. No round trip. A handful of images becomes a PDF in the time it takes to click.
Offline. Once the page is loaded, it works with the network off.

The only real cost is memory. Very large images held in a canvas use RAM, so a phone will tap out sooner than a laptop. For everyday scans and photos, that ceiling is high enough that you will not hit it.

The DIY way with jsPDF

If you want to build this yourself, jsPDF does the heavy lifting. It creates a PDF in memory and lets you drop an image onto each page.

import { jsPDF } from "jspdf";

function loadImage(url) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => resolve(img);
    img.onerror = reject;
    img.src = url;
  });
}

async function imagesToPdf(files) {
  const doc = new jsPDF({ unit: "px", format: "a4" });
  const pageW = doc.internal.pageSize.getWidth();
  const pageH = doc.internal.pageSize.getHeight();

  for (let i = 0; i < files.length; i++) {
    const url = URL.createObjectURL(files[i]);
    const img = await loadImage(url);
    if (i > 0) doc.addPage();
    doc.addImage(img, "JPEG", 0, 0, pageW, pageH);
    URL.revokeObjectURL(url);
  }
  doc.save("images.pdf");
}

Wire that to a file input and you have a working converter in about 25 lines.

<input type="file" accept="image/*" multiple
       onchange="imagesToPdf(this.files)">

Keep in mind what this simple version skips: it stretches every image to fill an A4 page, ignores aspect ratio, and offers no margins, ordering, or compression. Handling all of that well is where a few lines turns into a few hundred.

The no-code way

When you just need the PDF and not a side project, a browser tool that already handles the edge cases is faster. Pixellize Images to PDF runs the whole conversion in your browser, so the files stay on your device, and it covers the parts the snippet above skips.

Drop in your JPG, PNG, or HEIC images and you get:

Ordering. Drag the thumbnails into the page order you want before you export.
Page setup. Pick A4, Letter, or fit-to-image, plus portrait or landscape and a margin.
Compress images. Shrink the output so the PDF is small enough for an upload cap.
Page numbers and grayscale. Handy for printed handouts and scanned documents.

Then hit Generate PDF and the file downloads. No account, no watermark, nothing uploaded.

A few tips that save reprints

Order before you export. Reordering pages after the PDF exists means redoing it. Sort the thumbnails first.
Match the page size to the destination. A4 for most of the world, Letter for the US. Fit-to-image keeps photos edge to edge with no white border.
Compress for upload limits. Portals that cap PDFs at a few MB are the usual reason a clean export gets rejected. Turn compression on.
Grayscale scanned text. A scanned document in grayscale is smaller and prints cleaner than a full-color one.
Watch orientation. Portrait photos on a landscape page get letterboxed. Set the orientation to match the images.

Wrapping up

Converting images to a PDF is one of those tasks that quietly does not need a server, and doing it in the browser keeps your files private and the whole thing instant. Build it with jsPDF when you want it inside your own app, or use a ready tool like Pixellize Images to PDF when you just need the file. Either way, your documents never have to leave your machine.

If you build the DIY version, drop a link in the comments. I am curious how people handle aspect ratio and ordering.

10 Free Developer Tools That Run 100% in Your Browser (No Signup, No Upload)

Simran Kaur — Tue, 09 Jun 2026 05:37:37 +0000

We have all done it. You are mid-debug, you need to pretty-print a chunk of JSON, so you paste it into the first "JSON formatter online" result you find. Then you remember that JSON had an auth token in it. Now it lives on someone else's server.

That nagging feeling is why I keep coming back to tools that run entirely in the browser. No upload, no account, no "we value your privacy" banner hiding a tracker. The page loads, JavaScript does the work on your machine, and nothing gets sent anywhere.

Below are 10 of these I actually use, all from Pixellize. They are free, there is no signup, and you can open your network tab and watch them make zero requests while they work. Open one in a tab and pin it.

1. JSON Formatter, Validator, and Tree View

The everyday one. Paste minified JSON, get it back indented, validated, and as a collapsible tree so you can actually navigate a deep payload.

// in
{"user":{"id":7,"roles":["admin","editor"],"active":true}}

// out
{
  "user": {
    "id": 7,
    "roles": ["admin", "editor"],
    "active": true
  }
}

The validator catches the trailing comma you cannot see at 2am. Tool: JSON Formatter.

2. CSS Compressor

Strips whitespace, comments, and the last newline from a stylesheet before you ship it. Handy when a build step is overkill and you just want a quick minified blob.

/* before */
.btn {
  color: #754ffe;
  padding: 12px 20px;
}

/* after */
.btn{color:#754ffe;padding:12px 20px}

Tool: CSS Compressor.

3. Hash Generator

MD5, SHA-1, SHA-256, and friends from any string, computed in the browser with the Web Crypto API. Good for checksums, cache keys, or comparing a file hash without installing anything.

sha256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Because it runs locally, you can hash something sensitive without it touching a server. Tool: Hash Generator.

4. Unix Timestamp Converter

The one I open three times a day. Paste a 1717900000, get a human date in your timezone and UTC. Go the other way too.

1717900000  ->  Sat, 08 Jun 2024 23:46:40 UTC

No more new Date(ts * 1000) in the console just to read a log line. Tool: Unix Timestamp Converter.

5. CSS Grid Generator

A visual way to build a grid-template and copy the CSS out. You drag the columns and rows, set gaps, and it hands you working code instead of you counting fr units by hand.

.grid {
  display: grid;
  grid-template-columns: 1fr 2fr 1fr;
  grid-template-rows: auto;
  gap: 16px;
}

Tool: CSS Grid Generator.

6. Case Converter

Rename-variable energy. Flip text between camelCase, snake_case, kebab-case, PascalCase, and UPPER/lower in one click. Saves you from hand-editing a list of 30 field names.

user profile id  ->  userProfileId  /  user_profile_id  /  user-profile-id

Tool: Case Converter.

7. Password Generator

Generates strong random passwords (and decent API-key-style strings) using the browser's crypto randomness, not Math.random(). Set the length, toggle symbols, copy. Since it never phones home, the value you generate is only ever in your clipboard.

Tool: Password Generator.

8. QR Code Generator

Drop in a URL, get a QR code you can download. Useful for a quick "open this on your phone" during testing, linking a staging build, or a deploy that needs a device check. Generated client-side, so a private staging URL does not leak to a QR service.

Tool: QR Code Generator.

9. Color Palette Generator

Build a coherent palette when you do not have a designer on call. Pick a base color, get tints, shades, and matching accents with their hex values ready to paste into your tokens.

:root {
  --brand: #754ffe;
  --brand-600: #5f3fe0;
  --brand-100: #efe9ff;
}

Tool: Color Palette Generator.

10. Lorem Ipsum Generator

The unglamorous workhorse. Generate placeholder paragraphs, sentences, or words to fill a layout before the real copy shows up. Pick the count, copy, move on.

Tool: Lorem Ipsum Generator.

Why "in the browser" actually matters

It is not just a privacy nicety. Client-side tools are also:

Faster. No round trip to a server, so the result is instant even on a flaky connection.
Offline-friendly. Once the page is loaded, most of these keep working with the network off.
Honest about your data. You can verify the claim yourself: open DevTools, watch the Network tab, run the tool, and see nothing leave the page.

That last point is the one I care about most. "We do not store your files" is a promise. Zero network requests is a fact you can check.

The rest of the kit

Pixellize has around 130 of these in total, including PDF tools, image utilities, and SEO checkers, all the same way: free, no signup, in your browser. If you live in the browser dev tools all day, the full toolbox is worth a bookmark.

What is the one small utility you open every single day? Drop it in the comments. I am always looking for the next tab to pin.

Every YouTube video has 5 thumbnails sitting at predictable URLs (and how to grab them in 10 lines)

Simran Kaur — Mon, 01 Jun 2026 09:35:51 +0000

You've probably searched for a YouTube thumbnail downloader at some point. Maybe you wanted to study a competitor's design, build a research collection, or just save a thumbnail of your own video before re-uploading. The first 10 results in Google are all the same: a site with a paste-URL input, a "Generate" button, and 14 third-party scripts that load before the download link appears.

Here's the thing: YouTube serves the same five thumbnail files at predictable URLs for every public video. No auth, no API key, no rate limit. The URL pattern hasn't changed since 2014.

The downloader sites are wrappers around img.youtube.com. You can skip them entirely.

The URL pattern

https://img.youtube.com/vi/<VIDEO_ID>/<QUALITY>.jpg

<VIDEO_ID> is the 11-character ID that appears in every YouTube URL. <QUALITY> is one of these:

Filename	Dimensions	Always available?
`maxresdefault.jpg`	1280×720	Only if creator uploaded a custom HD thumbnail
`sddefault.jpg`	640×480	Yes
`hqdefault.jpg`	480×360	Yes
`mqdefault.jpg`	320×180	Yes
`default.jpg`	120×90	Yes (used in playlist UI)

Try it now. Paste this in your browser bar (it's PSY's "Gangnam Style" — definitely public):

https://img.youtube.com/vi/9bZkp7q19f0/maxresdefault.jpg

There's the thumbnail. Right-click, Save Image As, done.

Extracting the video ID from any URL

YouTube has at least 7 URL formats — standard watch, share link, Shorts, embed, music, mobile, old player. The 11-character ID lives in a different position depending on format. One regex catches them all:

const extractYouTubeId = (url) => {
  const match = url.match(/(?:v=|youtu\.be\/|shorts\/|embed\/|\/v\/)([\w-]{11})/);
  return match?.[1];
};

// Test cases
extractYouTubeId('https://youtube.com/watch?v=9bZkp7q19f0');         // → '9bZkp7q19f0'
extractYouTubeId('https://youtu.be/9bZkp7q19f0?t=42');                // → '9bZkp7q19f0'
extractYouTubeId('https://youtube.com/shorts/abc123xyz4_');           // → 'abc123xyz4_'
extractYouTubeId('https://youtube.com/embed/9bZkp7q19f0');            // → '9bZkp7q19f0'
extractYouTubeId('https://music.youtube.com/watch?v=9bZkp7q19f0');    // → '9bZkp7q19f0'
extractYouTubeId('https://m.youtube.com/watch?v=9bZkp7q19f0');        // → '9bZkp7q19f0'

The character class [\w-]{11} matches exactly 11 characters of word-chars or hyphens (YouTube IDs use letters, numbers, hyphen, underscore — and are always 11 chars long).

The 10-line bookmarklet

Drop this in your browser bookmarks bar. Click it on any YouTube watch page and the maxresdefault thumbnail opens in a new tab:

javascript:(function() {
  const m = location.href.match(/(?:v=|youtu\.be\/|shorts\/|embed\/)([\w-]{11})/);
  if (m) {
    window.open(`https://img.youtube.com/vi/${m[1]}/maxresdefault.jpg`, '_blank');
  } else {
    alert('Not a YouTube video URL');
  }
})();

To install: create a new bookmark, name it "YT Thumb", paste the entire javascript:... string above as the URL. Click it on any YouTube page.

The 404 gotcha nobody mentions

About 40% of YouTube videos return a 404 at /maxresdefault.jpg. This trips up every naive downloader.

The HD thumbnail file only exists when the creator uploaded a custom thumbnail at 1280×720 or larger. Auto-generated thumbnails (the three frame previews YouTube picks when you don't upload one) and pre-2014 uploads don't have a maxres file.

The fix: check sizes in priority order and use the first one that returns 200.

const sizes = ['maxresdefault', 'sddefault', 'hqdefault', 'mqdefault', 'default'];

async function getBestThumbnail(videoId) {
  for (const size of sizes) {
    const url = `https://img.youtube.com/vi/${videoId}/${size}.jpg`;
    const res = await fetch(url, { method: 'HEAD' });
    if (res.ok) return { url, size };
  }
  return null;
}

Note the method: 'HEAD' — you only care about the status code, not the file body. Saves bandwidth and latency.

CORS, or why you can't fetch the image client-side

If you try this in a browser script:

fetch(`https://img.youtube.com/vi/${id}/maxresdefault.jpg`)
  .then(r => r.blob())
  .then(blob => /* download blob */);

…you'll get a CORS error. img.youtube.com doesn't set Access-Control-Allow-Origin, so the response body is hidden from JavaScript. The HEAD check above works because you're only checking status; the image itself can't be read into a Blob.

Three workarounds:

window.open(url) — opens the image in a new tab, user right-clicks to save. No CORS issue because the browser is fetching for display, not for JS.
<a download> link — set href to the image URL, click programmatically. Same idea: browser handles the download, JS doesn't touch the bytes.
Server proxy — your backend fetches the image (no CORS at server-to-server), returns it to your frontend with proper CORS headers. Required if you want to repackage as ZIP or apply edits.

YouTube Shorts

Shorts use the same backend as regular videos. The thumbnail file pattern is identical — only the URL format changes (youtube.com/shorts/<ID> instead of ?v=<ID>). The regex above already handles this case.

One thing to know: even though Shorts display in portrait (9:16), the file YouTube serves is still landscape 16:9 with letterboxing or padding. If you want the actual portrait frame, you need the YouTube Data API.

Show DEV: my hosted version

I built Pixellize YouTube Thumbnail Downloader for the times when "paste a URL, click download" is faster than touching a bookmark. It runs the fallback chain automatically, parses every YouTube URL format the regex above catches, shows you what's available before you commit to a download, and has zero analytics scripts in the page. No signup, no daily limit, no watermark.

I built it because the existing free downloaders all violate one of these:

Multiple ads above the download link
Aggressive newsletter popups
Account required for "premium" sizes
Mobile redirects to apps

Three rules I wrote it under: don't load third-party scripts (zero tracking pixels), don't gate any quality behind a signup, render the result faster than the ads on competitor sites would have loaded.

Source code for the bookmarklet above + the fallback function are MIT licensed; you can wire them into your own tool. The hosted version handles the edge cases (CORS workaround via server fetch, age-restricted video detection, deleted-video graceful failure) so users get a working result without troubleshooting.

What I learned

The simplest URL pattern beats every "tool" abstraction. Knowing img.youtube.com/vi/<ID>/<QUALITY>.jpg makes 90% of "free YouTube thumbnail downloader" sites obsolete for developers.
CORS is the only meaningful ceiling. Once you accept that the browser can't read the image bytes directly, you stop fighting it and use window.open or <a download>.
The 40% maxresdefault gap is real. If you're building a tool, the fallback chain is the difference between "works for most videos" and "works for every public video".
A 10-line bookmarklet replaces a 200-script download site. Sometimes the right answer is a one-liner pasted in your bookmark bar, not a SaaS subscription.

If you want the hosted version, here it is: pixellize.io/youtube-thumbnail-downloader. If you'd rather build your own, the code above is everything you need.

Happy to answer questions about the implementation in the comments.

Auto-Convert Every WordPress Upload to WebP (Free, No Cloud Service)

Simran Kaur — Fri, 29 May 2026 12:45:56 +0000

If you have ever run a Lighthouse audit on a content-heavy WordPress site, you know the usual verdict: "Serve images in next-gen formats." Translation: your JPEGs and PNGs are too heavy, and WebP would cut them down a lot.

The problem is that nobody wants to convert images by hand, and most automated options either run as a bulk job you have to remember to trigger, or push your images to a cloud service with a monthly quota.

I wanted something simpler: upload an image, get a WebP, done. So I built a free plugin called Pixellize Image Optimizer, and this post walks through the problem, how the plugin solves it, and how it works under the hood.

Why WebP is worth it

WebP files are usually 25 to 35 percent smaller than the equivalent JPG or PNG at the same visual quality.
On an image-heavy page that is a real difference:

Faster Largest Contentful Paint, which is one of the Core Web Vitals Google uses for ranking.
Less bandwidth, which matters if you pay for CDN traffic.
No visible quality loss at sensible quality settings.

Browser support is no longer a concern. Every current browser handles WebP.

The approach: convert on your own server, on upload

Instead of a cloud API, the plugin converts images locally with the PHP GD or Imagick extension (almost every host has one). There is no account, no API key, and no paid tier.

The core flow:

You upload an image to the Media Library as usual.
The plugin generates a WebP version of the full image and every thumbnail size.
Your front end serves the WebP automatically.

How it works under the hood

For WordPress developers, here is the interesting part. The plugin hooks into the standard upload and rendering pipeline rather than fighting it:

On upload, it taps into the attachment metadata generation so it can convert the full image and every registered sub-size, not just the original. That matters because responsive images use srcset, and a half-converted set defeats the purpose.
On the front end, it rewrites image URLs to the WebP version through the same filters WordPress already uses: attachment image source, the responsive srcset, and post content. If a WebP does not exist for a given file, the original is served, so nothing breaks.
File naming mirrors the original: image.jpg becomes image.webp, and a duplicate upload that WordPress renames to image-1.jpg gets image-1.webp. No surprises.

Keep your originals, or save the space

This is the part I am happiest with in version 0.4. You get to choose:

Replace mode (default): the upload becomes a single WebP and the original is removed to save disk space.
Keep mode: the original stays in your Media Library, a WebP is built alongside it, visitors are served the WebP, and you can put any image back to its original whenever you want.

In keep mode there is a one-click Restore action in the Media Library that points an attachment back at its source file and rebuilds its sizes. And when you delete an image, the plugin cleans up the WebP copies with it, so you do not end up with orphaned files piling up on disk.

Getting started

Install "Pixellize Image Optimizer" from the WordPress plugin directory and activate it. It checks for GD or Imagick before activating.
Optionally visit Tools then Pixellize Image Optimizer to set the WebP quality. The default of 85 is a good balance for most sites.
Upload images the way you always do.

That is the whole workflow. The settings page also shows a savings panel: how many images were converted and how much storage you have saved.

A note on quality

Quality is adjustable from 0 to 100. A value between 80 and 90 keeps images looking clean while still cutting file size meaningfully. Going below 60 starts to show visible artifacts on detailed photos, so I would not push it lower without checking the results.

What is next

Bulk conversion of images you uploaded before installing the plugin is the next big feature on my list, followed by an option to resize oversized images on upload.

Try it

The plugin is free and open source (GPL):
https://wordpress.org/plugins/pixellize-image-optimizer

If you try it, I would genuinely like to hear what works, what breaks, and what you would want next. Drop a comment or open a thread on the plugin support page.

Set published: false so you can preview on dev.to first, then flip to true. Want me to add a cover image line, a code snippet showing the WordPress filter usage, or trim it shorter for a quicker read?

DEV Community: Simran Kaur

How to Check a Page's Canonical URL Programmatically (Node.js)

Where canonical URLs actually live

Reading the canonical in Node

Classifying what the canonical means

Bulk-checking a whole site

The one people miss: IP canonicalization

When you just need an answer, not a script

Takeaways

Convert CSV to Excel (XLSX) in JavaScript, in the Browser and in Node

The one-liner that works for clean data

Keeping leading zeros, long numbers, and dates intact

Doing it entirely in the browser

Batch converting a folder in Node

When you just need it once, without writing code

Takeaways

How to Detect What WordPress Theme (and Stack) a Website Uses

The five signals that give WordPress away

Checking by hand

Scripting it

Why detection sometimes fails

When you just want the answer

Wrap up

Meta Title and Description Length: What Google Actually Cuts Off

Why length matters at all

The numbers worth remembering

Reading them from the DOM

The part people skip: the SERP preview

A faster way to check

The takeaway

How to Convert Text to Binary (and Back) in JavaScript

What "binary" actually means here

Text to binary in JavaScript

Binary back to text

The UTF-8 catch that trips people up

When you just need the answer, not the code

Wrap up

How to Extract a .7z File Online Without Installing Anything

What a .7z file actually is

The usual options, and why they are annoying

Extract a 7z file online, in your browser

It handles the tricky cases too

When a desktop app still makes sense

Quick answers

Saving a tweet as a PDF is harder than it looks (CORS, tokens, and Unicode)

Wall 1: you cannot read a tweet from the browser

The fix: a tiny server-side proxy

Wall 2: the mysterious token

Wall 3: images taint the canvas

Wall 4: jsPDF breaks on Hindi and emoji

Putting the card together

Bonus: PNG export for free

Lessons

Convert Images to PDF in the Browser (No Upload, No Server)

Why do it client-side?

The DIY way with jsPDF

The no-code way

A few tips that save reprints

Wrapping up

10 Free Developer Tools That Run 100% in Your Browser (No Signup, No Upload)

1. JSON Formatter, Validator, and Tree View

2. CSS Compressor

3. Hash Generator

4. Unix Timestamp Converter

5. CSS Grid Generator

6. Case Converter

7. Password Generator

8. QR Code Generator

9. Color Palette Generator

10. Lorem Ipsum Generator

Why "in the browser" actually matters

The rest of the kit

Every YouTube video has 5 thumbnails sitting at predictable URLs (and how to grab them in 10 lines)

The URL pattern

Extracting the video ID from any URL

The 10-line bookmarklet

The 404 gotcha nobody mentions

CORS, or why you can't fetch the image client-side

YouTube Shorts

Show DEV: my hosted version

Wall 2: the mysterious `token`