DEV Community: Hao

Your YouTube screenshot is black because you screenshotted the wrong layer

Hao — Sat, 25 Jul 2026 03:55:50 +0000

You hit PrintScreen on a video, paste, and get a black rectangle where the picture was. The window
frame is there. The controls are there. The video is a hole.

The video was never in the pixels you copied.

What actually happened

A hardware-accelerated video does not get painted into the same surface as the rest of the window.
The decoder hands frames to the GPU, which composites them into an overlay plane at the very last
step, after the window contents have been assembled. A screen capture that reads the window surface
reads what is underneath that plane, which is the punch-out colour: black.

This is why the same PrintScreen works fine on some machines and fails on others, why it starts
failing after a GPU driver update, and why "disable hardware acceleration" is the advice that keeps
getting handed out. Turning off acceleration does fix it, by making the video render into the normal
paint path, along with the battery cost.

The better move is to stop capturing the window and ask the <video> element for the frame instead.

Grab the frame from the element

drawImage accepts a <video> and reads the frame it is currently showing:

const v = document.querySelector("video");
const c = document.createElement("canvas");
c.width = v.videoWidth;          // NOT v.clientWidth
c.height = v.videoHeight;
c.getContext("2d").drawImage(v, 0, 0);
c.toBlob(b => open(URL.createObjectURL(b)), "image/png");

Paste that into the console on a YouTube tab and you get the exact frame, no black.

The one line worth staring at is v.videoWidth. That is the resolution of the decoded stream, which
is what you want. clientWidth is the size of the CSS box, so using it silently downsamples a 4K
frame to whatever your player happens to be sized at in that window. This is the difference between a
usable still and a soft 640-pixel-wide one, and it is easy to get wrong because both produce an image.

Set the player to 2160p first if you want 2160p out. videoWidth reports the stream YouTube is
currently feeding you, not the best one available.

Straight to the clipboard

Skipping the file is often what you want, since the frame is usually headed for a slide or a note:

const png = await new Promise(r => c.toBlob(r, "image/png"));
await navigator.clipboard.write([new ClipboardItem({ "image/png": png })]);

Two constraints that will bite you. The clipboard only takes PNG here, so if you produced a JPEG
blob you have to re-encode before writing. And clipboard.write needs a user gesture and a focused
document, so it works from a click handler and fails from a setTimeout.

When it still comes out black

drawImage on a DRM-protected video throws instead of returning pixels. Widevine-protected content —
a rented film, most paid streaming — is out of reach by design, and no extension or console snippet
changes that. YouTube's ordinary videos are not protected, so they are fine.

Wrap it, because an unhandled throw here looks identical to a broken tool:

try { ctx.drawImage(v, 0, 0); } catch { /* protected stream */ }

Naming the file

If you are saving rather than copying, put the timestamp in the name while you still have it:

const t = Math.floor(v.currentTime);
const stamp = `${String(t/3600|0).padStart(2,"0")}-${String(t/60%60|0).padStart(2,"0")}-${String(t%60).padStart(2,"0")}`;

Frames without a timestamp in the filename are unfindable a week later, which anyone who has taken
lecture notes this way has learned the hard way.

The extension

I packaged this as Screenshot for YouTube — Video Frame
Capture. Disclosure:
mine, free, no account, no network requests.

It puts a camera button in the player controls, binds Alt+S, saves PNG or JPEG or copies to the
clipboard, and names files with the video title plus the timestamp above. There is a popup capture
button as a fallback for Shorts and embeds, where the standard control bar is absent. Getting the
button to survive YouTube's SPA navigation needed a MutationObserver plus the yt-navigate-finish
event, which is the least interesting and most fiddly part of the whole thing.

If you only need one frame today, the console snippet above is the entire mechanism. The extension
exists because the twentieth time you do it by hand, videoWidth is not the thing you want to be
remembering.

Why the most-installed "PDF dark mode" Chrome extensions do nothing on a web PDF

Hao — Sat, 25 Jul 2026 03:54:35 +0000

Chrome still ships no dark mode for its built-in PDF viewer. Open a white paper at 1am and you get a
flashbang. So you go to the Web Store, install the extension with the most installs, click it, and…
nothing happens. The page stays white.

I went and read the manifests of the top results to find out why. Two reasons, and both are boring.

Reason 1: the popular ones only handle `file://`

The extension named "PDF Dark Mode" (about 10,000 users, rated 2.5) declares exactly this:

"permissions": ["scripting", "declarativeContent"],
"host_permissions": ["file:///*.pdf"]

The runner-up, "PDF Dark Theme" (about 9,000 users, rated 2.9), does the same thing with a content
script:

"content_scripts": [{ "matches": ["file://*.pdf"], "js": ["content-script.js"] }]

file:///*.pdf matches a PDF you dragged in from your own disk. It does not match
https://arxiv.org/pdf/1706.03762, or the invoice your bank linked, or the syllabus on a course
site. That is where almost everyone actually meets a PDF. So the extension is installed, enabled,
and structurally incapable of touching the document in front of you.

To be fair about the scope of this: it is the two most-installed ones that are scoped this way,
not the whole category. Several smaller ones (a few hundred to a few thousand users) request
<all_urls> or use activeTab and do handle web PDFs. The ranking is weighted by install count, so
the two that cannot do the common case are the two you see first.

This is also why the reviews are full of people being told to flip "Allow access to file URLs" and
reporting back that it changed nothing. It was never the missing piece.

You can check any extension for this in ten seconds: chrome://extensions → Details → look at
"Site access". If it says nothing beyond file URLs, that is your answer.

Reason 2: the CSS target moved

The other approach is a CSS filter on the viewer element:

embed[type="application/x-google-chrome-pdf"] { filter: invert(90%) hue-rotate(180deg); }

That used to be right. When you navigate straight to a PDF today, the document you are styling has
no <embed> in it. The viewer lives in an out-of-process child frame that your CSS cannot reach.
Your selector matches zero elements and fails silently, which is the worst way for CSS to fail.

What does reach it is a filter on the root element of the PDF document itself:

html { filter: invert(90%) hue-rotate(180deg); background-color: #17171a; }

So the two cases need different code, and you can tell them apart cheaply:

const topLevelPdf = document.contentType === "application/pdf";
const css = topLevelPdf
  ? `html { filter: ${f} !important; background-color: #17171a !important; }`
  : `embed[type="application/x-google-chrome-pdf"],
     embed[type="application/pdf"],
     object[type="application/pdf"] { filter: ${f} !important; }`;

An embedded PDF (a viewer inside a normal page) still wants the second form, because filtering
html there would invert the surrounding page too.

Try it without installing anything

Open a PDF in Chrome, open DevTools on it, and paste this into the console:

document.documentElement.style.filter = "invert(90%) hue-rotate(180deg)";
document.documentElement.style.backgroundColor = "#17171a";

Two notes on the numbers, because they matter more than they look.

invert(90%) rather than invert(100%): full inversion turns black text into pure white on pure
black, which vibrates unpleasantly at night. 90% lands on a soft grey.

hue-rotate(180deg) after the inversion: inverting alone also inverts hue, so a blue hyperlink comes
out orange and a red warning box comes out cyan. Rotating the hue 180° puts colours back where they
started while keeping the lightness flipped. Skip it and PDFs with charts become unreadable.

Sepia is the same trick with one more stage:

filter: invert(93%) hue-rotate(180deg) sepia(35%);

What this approach cannot do

Be honest about the limits before you build on it:

Photographs and diagrams invert along with the text. A CSS filter has no idea which pixels are content and which are background. Nobody solves this with filter; it needs the PDF parsed and re-rendered.
DRM-protected PDFs are outside your reach entirely.
The console trick dies on reload. Persisting it is the entire reason extensions exist here.

The extension

I got tired of this and wrote the small version: PDF Dark Mode — Night Reader for
PDFs. Disclosure: mine,
free, no account, no network calls at all.

It does the branch above, so web PDFs work and not only local ones; it uses activeTab so it reads
one tab when you click it and holds no standing permission on your browsing; the three themes are
soft dark, true black and sepia, with brightness and contrast sliders.

If you would rather not install a thing, the console snippet is genuinely the whole idea. Take it.
The frustrating part of this category was never the CSS. It was ten extensions all quietly scoped
to file://.

Fragrance notes, accords and ratings as JSON, without fighting Fragrantica's Cloudflare

Hao — Fri, 24 Jul 2026 04:47:54 +0000

A dupe/clone finder, a fragrance shop's product enrichment, a rating tracker, a
recommendation engine based on notes: they all need the same raw material, which is
structured notes, accords, and ratings per fragrance, not prose reviews. Demand for that
data is well proven, since Fragrantica scrapers on Apify have 1,700+ combined runs
between them. Sourcing it has gotten harder, though, and that is worth understanding before
you pick a source.

Why the obvious source (Fragrantica) is the wrong first pick

Fragrantica is the biggest fragrance database, so it's the first thing everyone scrapes.
But it now sits behind Cloudflare, and most of the scrapers built against it are
fighting that wall. You'll find a handful on Apify, several with visibly stale runs or
low success rates, because the site actively blocks plain requests. You end up paying in
proxy cost, retries, and broken runs for data that's conceptually simple: notes, accords,
a rating.

Parfumo is the other large, community-driven fragrance encyclopedia, with comparable
scale and depth of data (notes, accords, per-dimension community ratings, perfumer credits),
and it still serves plain, uncached HTML with no Cloudflare challenge. As of this writing it
had zero dedicated scrapers on Apify. So the demand signal for this class of data is
proven (1,700+ runs on the Fragrantica side alone), while almost all of the tooling points
at the one source that is actively fighting back.

What the source data looks like, cleaned up

One record per fragrance, real output for Dior Sauvage EDT:

{
  "name": "Sauvage",
  "brand": "Dior",
  "releaseYear": 2015,
  "concentration": "Eau de Toilette",
  "gender": "men",
  "rating": { "value": 7.5, "best": 10, "ratingCount": 6514, "reviewCount": 365 },
  "perfumers": ["François Demachy"],
  "accords": ["Fresh", "Spicy", "Synthetic", "Citrus", "Woody"],
  "notes": ["Ambrox", "Sichuan pepper", "Calabrian bergamot", "Pink pepper", "..."],
  "communityRatings": {
    "scent":     { "average": 7.30, "votes": 6514 },
    "longevity": { "average": 7.79, "votes": 6129 },
    "sillage":   { "average": 7.73, "votes": 6106 },
    "bottle":    { "average": 7.72, "votes": 6164 },
    "value":     { "average": 7.40, "votes": 4561 }
  }
}

When a page groups notes into a pyramid (most designer releases do), you also get:

"notesPyramid": {
  "top":   ["Bergamot", "Apple", "Blackcurrant", "Lemon", "Pink pepper"],
  "heart": ["Pineapple", "Indonesian patchouli", "Jasmine"],
  "base":  ["Birch", "Cedarwood", "Musk", "Oakmoss", "Ambergris"]
}

The pyramid, rather than a flat note list, is what a dupe/clone finder actually needs. Two
fragrances can share a base note and read completely differently because their top notes
diverge, so comparing pyramids beats comparing flat sets.

Getting it without hand-copying spec pages

Parfumo Fragrance Scraper
on Apify takes a list of perfume URLs (or Brand/slug pairs) and returns one clean record
per fragrance:

curl -s -X POST "https://api.apify.com/v2/acts/minty_modesty~parfumo-perfume-data-scraper/runs?token=$APIFY_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"perfumeUrls":["Dior/sauvage","Creed/aventus","Chanel/No_5"],"includeCommunityRatings":true}'

It reads only public /Perfumes/ pages, which Parfumo's robots.txt allows. No login, no
CAPTCHA, no Cloudflare challenge to route around, so a run doesn't turn into a proxy bill.
URLs that don't resolve come back as {"url": "...", "error": "not_found"} instead of
silently dropping the line item, so a batch of a few hundred references doesn't need
babysitting.

When this is (and isn't) the right layer

If you already have a working Fragrantica pipeline and it isn't breaking, there's no reason
to switch sources mid-project. But if you're starting a new dupe-finder, enrichment job, or
rating tracker from scratch, the 1,700+ runs on the Fragrantica side tell you the data is
worth having. They don't tell you Fragrantica is the only place to get it. Parfumo is the
same class of data from a source that isn't actively trying to block you from reading it.

Turn a watch reference number into full specs (caliber, case, dial) as JSON

Hao — Fri, 24 Jul 2026 04:18:32 +0000

A marketplace, a valuation tool, an insurance quoting flow, a collection tracker: build
anything around watch data and you eventually hit the same wall. You have a reference
number (126500LN-0001, scraped from a listing or copied off an invoice) and you need the
spec sheet behind it: movement/caliber, case material, dimensions, water resistance,
dial color and finish. The listing itself never has all of this. Where
does it actually live, and how do you get it as clean data instead of copy-pasting spec
tables by hand?

The gap in the watch-data ecosystem

Watch marketplace scraping is a solved, proven market. Chrono24 scrapers on Apify have
16,000+ runs, so people clearly pay for watch listing data. But a listing gives you
price, seller, condition, and a reference number. It does not give you the manufacturer's
full technical spec for that reference. That data lives on dedicated
reference databases, not on the marketplaces themselves.

The reference-grade source for this is WatchBase, a structured database organized
brand → model family → individual reference, with every spec Rolex, Omega, Seiko, and
hundreds of other brands publish for each watch. It has no public API and no search
endpoint, only a browsable page hierarchy, which is exactly why this data usually ends
up copy-pasted into spreadsheets one watch at a time.

What the source data looks like, cleaned up

One record per reference, normalized to the fields you actually compare across watches:

{
  "brand": "Rolex",
  "family": "Daytona",
  "reference": "126500LN-0001",
  "name": "Cosmograph Daytona Stainless Steel - Cerachrom / White / Oyster",
  "caliber": "Rolex caliber 4131",
  "movement": "Rolex caliber 4131 Hours, Minutes, Small Seconds | Chronograph, Column wheel | Chronometer",
  "material": "Ceramic, Stainless Steel",
  "glass": "Sapphire",
  "diameterMm": 40,
  "heightMm": 11.9,
  "waterResistanceM": 100,
  "dialColor": "White",
  "indexes": "Stick / Dot",
  "specs": { "...": "every raw label/value pair WatchBase publishes for this reference" }
}

The specs object matters as much as the normalized top-level fields: field coverage
varies a lot by watch (a current Rolex has far more documented fields than a 1960s
piece), and WatchBase's own labels vary slightly between brands (Material vs
Materials). Keeping the raw label/value pairs alongside the normalized fields means you
never lose data to an over-eager parser.

Getting it without hand-copying spec tables

Rather than walking WatchBase's brand → family → reference hierarchy yourself, you can
run a hosted actor that already does the discovery and normalization:
WatchBase Scraper on Apify.

Give it a brand (or a list of specific reference URLs if you already have them):

{
  "brands": ["rolex"],
  "maxItems": 200,
  "includeMovement": true,
  "includeCaseSpecs": true,
  "includeDialSpecs": true
}

curl -s -X POST "https://api.apify.com/v2/acts/minty_modesty~watchbase-scraper/runs?token=$APIFY_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"brands":["rolex"],"maxItems":200}'

It reads only public reference pages (plain server-rendered HTML, allowed by
robots.txt, no login) and returns one clean record per watch. If you already have
reference numbers from a marketplace dataset, pass referenceUrls instead of a whole
brand and skip straight to the records you need.

When this is (and isn't) the right layer

If you only need one or two watches, just open the WatchBase page. If you're enriching a
marketplace dataset in bulk, hydrating thousands of Chrono24-style listings with the
manufacturer spec behind each reference, that is exactly the gap this fills. Listing
scrapers get you price and reference number; this gets you everything after that.

How to get LCSC component prices and stock as JSON (no login, no API key)

Hao — Thu, 23 Jul 2026 18:23:28 +0000

If you build hardware, you have hit this: you have a BOM full of LCSC part codes
(C1591, C25804, the C##### numbers on every LCSC and JLCPCB line item), and you
want the live price ladder and stock as structured data, so you can cost a build,
watch prices, or enrich a component database. LCSC has no public pricing API, and
the search endpoints are protected. So how do you get the data cleanly?

This post shows the pragmatic approach, why the obvious ones break, and a zero-setup
way to get one clean JSON record per part.

Why the obvious approaches break

Scraping the search API. It is rate-limited and CAPTCHA-protected; reverse- engineering it means fighting anti-bot systems that change often. High-maintenance.
Headless-browser clicking. Heavy, slow, and brittle against layout changes.
Manual copy-paste. Fine for three parts, not for a 200-line BOM you re-cost weekly.

The stable surface is the public product-detail page (/product-detail/...). It is
allowed by LCSC's robots.txt, it carries the full data (price tiers, stock, package,
MOQ, parametric specs, datasheet URL) in the page's own JSON, and it does not require a
login. Read that, one lightweight request per part, and you get reliable results
without an anti-bot arms race.

The data you actually want, per part

{
  "productCode": "C1591",
  "mpn": "CL10B104KB8NNNC",
  "brand": "Samsung",
  "description": "100nF ±10% 50V X7R 0603 MLCC",
  "stock": 512340,
  "package": "0603",
  "minOrderQty": 50,
  "priceTiers": [
    { "qty": 50, "usd": 0.0019 },
    { "qty": 500, "usd": 0.0011 },
    { "qty": 5000, "usd": 0.0007 }
  ],
  "datasheetUrl": "https://...",
  "url": "https://www.lcsc.com/product-detail/C1591.html"
}

That is spreadsheet-ready and diff-able: store it, re-fetch weekly, and you can watch
price and stock move over time.

The zero-setup route

Rather than maintain scraper code yourself, you can run a hosted actor that does exactly
the above. It reads only public product pages and returns one clean record per code:
LCSC Parts Scraper on Apify.

Input is just your list of codes:

{
  "productCodes": ["C1591", "C25804", "C7593"],
  "includePriceTiers": true,
  "includeSpecs": true
}

Call it from the API / CLI and pull the dataset as JSON or CSV:

# start a run and wait, then fetch the dataset
curl -s -X POST "https://api.apify.com/v2/acts/minty_modesty~lcsc-parts-scraper/runs?token=$APIFY_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"productCodes":["C1591","C25804"],"includePriceTiers":true}'

Because it reads public pages at low volume, it keeps working where search-API scrapers
get blocked. Feed it your BOM, get back cost data.

When to roll your own instead

If you only ever need a couple of parts, just open the product page. If you need
keyword → part codes, resolve codes first (from your BOM or on lcsc.com), because this
approach is deliberately code-first to stay on stable pages. And if you need account-
specific contract pricing, that lives behind your LCSC login and no public method will
reach it.

For the common case, turning a list of LCSC codes into clean, structured price/stock/spec
data for BOM costing or price monitoring, reading the public product pages is the reliable
path, and a hosted actor removes the maintenance entirely.

DEV Community: Hao

Your YouTube screenshot is black because you screenshotted the wrong layer

What actually happened

Grab the frame from the element

Straight to the clipboard

When it still comes out black

Naming the file

The extension

Why the most-installed "PDF dark mode" Chrome extensions do nothing on a web PDF

Reason 1: the popular ones only handle file://

Reason 2: the CSS target moved

Try it without installing anything

What this approach cannot do

The extension

Fragrance notes, accords and ratings as JSON, without fighting Fragrantica's Cloudflare

Why the obvious source (Fragrantica) is the wrong first pick

What the source data looks like, cleaned up

Getting it without hand-copying spec pages

When this is (and isn't) the right layer

Turn a watch reference number into full specs (caliber, case, dial) as JSON

The gap in the watch-data ecosystem

What the source data looks like, cleaned up

Getting it without hand-copying spec tables

When this is (and isn't) the right layer

How to get LCSC component prices and stock as JSON (no login, no API key)

Why the obvious approaches break

The data you actually want, per part

The zero-setup route

When to roll your own instead

Reason 1: the popular ones only handle `file://`