DEV Community: Simran Kaur

Check any site's Domain Rating free, from the browser or a curl one-liner

Simran Kaur — Sat, 10 Oct 2026 13:03:15 +0000

If you do outreach, guest posting, or competitor research, you have wanted one number without opening the 129 dollar a month Ahrefs dashboard: Domain Rating. Here are two zero-cost ways to get it, a no-signup web tool and a curl one-liner.

What DR actually is

Domain Rating (DR) is Ahrefs' 0 to 100 score of a site's backlink strength. It is logarithmic, so 20 to 30 is easy and 70 to 80 is brutal. DR is not a Google ranking factor, but it correlates with the link profiles that tend to rank, so it is a fair gut check before you spend time on a site.

Option 1: the no-setup web tool

Paste a domain into the Domain Rating Checker, hit the button, and you get the real Ahrefs DR on a 0 to 100 gauge with a strength label. No login, single or bulk, CSV export.

Option 2: curl the free Ahrefs endpoint

Ahrefs shipped a free public DR endpoint. Generate a free API key in your Ahrefs account settings, then:

curl -s "https://api.ahrefs.com/v3/public/domain-rating-free?target=example.com&version=dr3&output=json" \
  -H "Authorization: Bearer YOUR_FREE_KEY"

Response:

{ "domain_rating": { "domain_rating": 91.0, "license": "https://ahrefs.com/legal/domain-rating-license" } }

No API units are consumed, and the key is free. Two gotchas worth knowing before you script against it:

There is a per-minute rate limit (roughly 40 to 60 requests per minute), so cache results if you loop.
Ahrefs' license requires attribution ("Domain Rating by Ahrefs") wherever you display the number.

If you do not want to manage a key at all, the web tool above does the same call server side and keeps the key off the client.

Bulk, for a shortlist

Bulk mode takes up to five domains at once and exports the table to CSV, which is enough for most link-vetting sessions.

For thousands of domains you need a paid Ahrefs plan with full API access. That is the honest ceiling of the free tier.

DR vs DA

Domain Rating is Ahrefs. Domain Authority is Moz. Different link indexes, different math, so the same site scores differently on each. Pick one and track the trend over time rather than mixing them.

Honest caveats

Free tier gives you DR only. Backlinks, referring domains, traffic, and keywords are paid.
DR is a proxy for authority, not a ranking guarantee.
A DR 35 page can still outrank a DR 70 page for a specific query if it is more relevant and better linked for that topic.

Tool: Domain Rating Checker. Full write-up: How to check domain rating.

Converting cm to pixels in code (the passport photo gotcha)

Simran Kaur — Mon, 05 Oct 2026 06:39:16 +0000

You would think converting centimeters to pixels is a fixed conversion. It is not. It depends on DPI, and that one detail quietly breaks photo-upload forms for millions of people every year.

Here is the function, and the gotcha.

The formula

pixels = cm / 2.54 * dpi

In JavaScript

const cmToPx = (cm, dpi = 300) => Math.round((cm / 2.54) * dpi);

cmToPx(3.5); // 413
cmToPx(4.5); // 531

In Python

def cm_to_px(cm, dpi=300):
    return round(cm / 2.54 * dpi)

cm_to_px(3.5)  # 413
cm_to_px(4.5)  # 531

So a 3.5 x 4.5 cm passport photo is 413 x 531 px at 300 DPI. And 35 x 45 mm is the same size.

The gotcha: DPI

The same centimeters map to a different pixel count at a different DPI:

DPI	3.5 x 4.5 cm
300	413 x 531 (print)
96	132 x 170 (screen)
72	99 x 128 (legacy)

If you build any image or document tool, default to 300 DPI for print and official output. Default to a screen DPI and your users ship blurry passport photos that get rejected.

Why it matters in the real world

Passport, visa, PAN, and exam forms ask for the size in cm but upload in pixels, with no conversion shown. 413 x 531 at 300 DPI is the value that works for almost all of them.

If you just need the output and not the code, I built a browser tool that locks to 413 x 531 at 300 DPI (nothing uploaded): 3.5 x 4.5 cm resizer. Full writeup with the size table: here.

What DPI does your image pipeline default to?

Unzip a file without installing anything (even on a locked-down work laptop)

Simran Kaur — Sun, 04 Oct 2026 06:36:28 +0000

You know the moment. A teammate drops a release-build.zip in Slack, you're on the work laptop, and IT has blocked every installer on earth. No 7-Zip, no WinRAR, no admin rights. The files you need are right there, sealed inside a container you can't open.

Here is every way I actually unzip files, from fastest-if-you-have-a-terminal to works-anywhere-even-on-a-managed-machine.

If you have a terminal, it's a one-liner

Both macOS/Linux and Windows ship with extraction built in. No install.

# macOS / Linux
unzip release-build.zip -d ./out

# list contents first, without extracting
unzip -l release-build.zip

# Windows PowerShell (built in since 5.0)
Expand-Archive release-build.zip -DestinationPath .\out

That covers 90% of dev machines. The other 10% is where it gets annoying.

When you can't touch the terminal

Locked-down work PC, a borrowed machine, a phone, or a reviewer who just wants the files without a CLI lecture. This is where a browser-based extractor earns its place. It runs the unzip client-side, so the archive is never uploaded anywhere.

I use Pixellize's unzip tool for this. Drop the .zip, it reads the archive in the tab, shows every entry with compressed vs original size, and you pull out one file or all of them. Nothing leaves the machine, which matters when the zip is a client deliverable under NDA, not just some icons.

no install • no account • archive stays in the browser

Password-protected zips

If you know the password, both the CLI and a decent browser tool handle it:

unzip -P 'the-password' secret.zip     # heads up: this lands in your shell history

If you don't know the password, stop looking for a magic "unlocker." Encrypted zips are real encryption. No honest tool cracks an unknown password, and the sites that claim to are the ones you don't want near a client file. Ask whoever made the archive to resend it.

Quick reference

Situation	Best move
You have a terminal	`unzip` / `Expand-Archive`
Locked work PC, no installs	browser extractor
Phone	Files app (iOS) / Files by Google (Android), or the browser tool
`.rar` / `.7z`	not plain zip, needs 7-Zip or a tool that reads them
Daily, multi-GB archives	just install 7-Zip, honestly

Gotchas that have burned me

__MACOSX/ and ._ junk after extracting a zip made on a Mac. Harmless, delete it.
Double-click does nothing usually means the file is a .rar wearing a .zip extension. Check with file archive.zip.
0 KB files after extraction means the download was truncated. Re-pull it, resumable: curl -C - -O <url>.
Weird filenames come from non-UTF-8 names zipped on another OS. The file itself is fine.

The rule I land on: for a quick, one-off extraction with nothing to install, do it in the browser and keep the bytes on your machine. For daily heavy use or odd formats, just install 7-Zip and move on.

Full writeup with the Windows/Mac/phone steps lives on the original post.

A free URL shortener with click analytics and no signup

Simran Kaur — Thu, 24 Sep 2026 16:27:16 +0000

As developers we share links constantly: a repo, a deploy preview, a doc, a demo in a tweet. Most URL shorteners make that harder than it needs to be. They want an account, they hide click stats behind a plan, and the link you create lives forever whether you want it to or not.

I have been using Pixellize's URL shortener because it fixes all three, and it is free. Sharing it here in case it saves you the same friction.

What it does

Shortens any link, with an optional custom name like /s/demo instead of a random code.
Shows real click analytics: total clicks, a 7-day chart, top referrers, and a device breakdown.
Lets links expire in 24 hours, 2 days, or 5 days, then deletes them automatically.
Needs no account, no email, and no credit card.

Why it is worth using

Click analytics are free. This is the part almost every other tool charges for. You paste your short link into the tracker and see how it performed, no login, no upgrade prompt.

It does not track the people who click. It stores a click count, the referring site, and a device type. No IP addresses, no profiles, no cookies. Good for you, and fair to whoever clicks your link.

Links expire on purpose. A preview link or a one-off share should not outlive its use. You pick a lifetime and the link cleans up after itself. Handy for temporary shares you do not want indexed or lingering.

No signup. Paste, shorten, share. That is the whole flow.

How it compares

Feature	Pixellize	Typical free tier
Click analytics	Free, built in	Often paid
Custom link name	Free	Varies
Expiring links	Yes	Rare
Account required	No	Usually yes for stats
Tracks the clicker	No	Often yes

Honest caveat: for a permanent link you will reuse for years, a bigger paid service still makes sense. This shines for the links you share this week.

How to use it

1. Paste your link and set the details.

2. Get your short link and copy it.

3. Track the clicks any time.

Try it

Free, no signup: pixellize.io/url-shortener. If you share links anywhere and want to know what actually gets clicked, it is worth a look.

Originally published at pixellize.io.

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.

DEV Community: Simran Kaur

Check any site's Domain Rating free, from the browser or a curl one-liner

What DR actually is

Option 1: the no-setup web tool

Option 2: curl the free Ahrefs endpoint

Bulk, for a shortlist

DR vs DA

Honest caveats

Converting cm to pixels in code (the passport photo gotcha)

The formula

In JavaScript

In Python

The gotcha: DPI

Why it matters in the real world

Unzip a file without installing anything (even on a locked-down work laptop)

If you have a terminal, it's a one-liner

When you can't touch the terminal

Password-protected zips

Quick reference

Gotchas that have burned me

A free URL shortener with click analytics and no signup

What it does

Why it is worth using

How it compares

How to use it

Try it

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?

Wall 2: the mysterious `token`