DEV Community: GlenKit

What Chrome Web Store review time actually looks like in 2026 (measured on 6 submissions)

GlenKit — Sun, 08 Nov 2026 14:01:31 +0000

Every few months someone asks "how long does Chrome Web Store review take now?" and the answers range from "two hours" to "three weeks". Both are true, because review time is not one number — it depends on what changed in the package. I keep timestamps for every submission of my extensions, so here is the real spread.

The short version

What you submitted	Observed time
Rejection (policy violation in the listing text)	~10 minutes
Update, same permissions, small feature set	same day – 1 day
Update that adds a permission	several days
First submission of a new extension	days to weeks

The pattern is boring and consistent: review time tracks the permission delta, not the amount of code.

The submissions I'm drawing from

Two extensions, both MV3, both already published:

CookieGuard — rejects cookie consent banners. Permissions: storage + host permission.
AnkiMate — turns web pages into Anki cards. Permissions: contextMenus, storage, sidePanel, scripting, tabs, host permission.

Neither runs remote code, and neither has widened its permission string since it was first approved. That last part matters more than anything else below.

Same-day approvals

CookieGuard 1.3.0 → 1.4.0. The change: the upgrade button stopped opening my website and started opening a Creem checkout URL, plus a yearly-plan link. Zero permission changes, a handful of new locale keys. Submitted on a Friday afternoon, live by the evening. The public listing page already showed the new version number a few hours later.

AnkiMate 1.3.0 → 1.4.0. Bigger in code — a fallback export path (TSV instead of AnkiConnect), a keyboard command (Alt+Shift+D), a trio of read-only AnkiConnect stats calls. Still the same permission string as 1.3.0. Submitted in the evening, live later that night.

CookieGuard 1.4.0 → 1.4.1. Per-site action overrides, a first-run welcome page, a reworked popup diagnostics line, and a rewritten store description submitted in the same pass. Approved within a day.

Three updates, three approvals, no extra review rounds. The only thing all three have in common: the permissions string did not change.

The ten-minute rejection

Earlier, on a different extension of mine, one submission came back in about ten minutes. It was not a code problem. The listing description listed competitor product names as a comparison — a trademark issue, not a functionality issue. The package was never inspected.

This is the failure mode people underrate: a policy rejection can arrive before a human ever looks at your extension, because listing text is checked mechanically. If you get a rejection in minutes, assume the description, not the code.

Why permission changes cost days

Chrome's review process escalates when the permission warning shown to users changes. The reviewer now has to judge whether the new capability is justified by what your description promises. That is a subjective call, so it goes into a slower queue.

Practical consequence: batch your permission changes. If you are going to add host access for one more API domain, ship it together with every other permission-adjacent change you have queued. Paying the slow review twice is the expensive mistake.

Corollary: if a release is genuinely permission-neutral, do not be afraid to ship it. Same-day approval is normal, not lucky.

Things that do not seem to affect review time

Number of locales. I ship 9 languages on both extensions. English-only builds and 9-language builds both got approved the same day.
Listing text changes bundled with a code update. One review covers both.
Screenshots and icon changes. No visible effect.
Description length, as long as it stays under the 16,000-character cap and does not read like keyword stuffing.

Things that do

A permission string that changes. Even one added host.
Remote code or remotely hosted logic. Anything that pulls executable instructions from your server is its own queue.
A description that makes claims the package does not implement. This one is not just slow, it is the thing people get rejected for. If your store page lists a Pro feature, assume a reviewer can install the extension and check — which is why I now grep my own codebase for every feature name that appears in a listing before submitting.
Touching the listing while a submission is in review. Wait. Editing mid-review can reset the state, and you lose the timestamp you were using to estimate.

How to actually measure this for yourself

Keep a small log: submission timestamp, permission diff (yes/no), what changed, approval timestamp. After four or five entries you will have a better estimate for your own extension than any blog post, including this one — review behaviour varies by category and by account history.

Two things I wish I had done from the start: write down the exact permission string of every released version (so "did this change?" is a diff, not a memory exercise), and diff the store description against the code before every submission.

The extensions in this log are CookieGuard and AnkiMate — both local-first, no telemetry, no account. I'm the developer, so treat the timings as one person's dataset, not an industry average.

Writing cards straight into Anki from a browser extension (AnkiConnect, without the hand-waving)

GlenKit — Wed, 04 Nov 2026 13:37:54 +0000

If you have ever built a tool that generates flashcards, you have probably stopped at the export step: produce a CSV or an APKG, hand it to the user, and let them import it into Anki themselves. That works, but it leaks users at every hop — the download, the import dialog, the field mapping, and the duplicate pile-up when they run your tool twice.

There is a better option, and it is an add-on most people have heard of but few have wired up: AnkiConnect. This post is the practical version of what that integration actually looks like from inside a browser extension — the parts the README does not cover.

What AnkiConnect actually is

AnkiConnect (add-on code 2055492159) runs a small local HTTP server inside desktop Anki, bound to 127.0.0.1:8765. It speaks JSON: you POST a payload like:

{
  "action": "addNote",
  "version": 6,
  "params": {
    "note": {
      "deckName": "Med school::Lectures",
      "modelName": "Basic",
      "fields": { "Front": "What is X?", "Back": "It is Y" },
      "tags": ["lecture-07"]
    }
  }
}

and Anki replies with a note id — or an error if the deck or model does not exist. That is the whole protocol. No cloud, no account, no file.

The part nobody warns you about: CORS

Here is the catch that turns a one-hour integration into a two-day one. AnkiConnect sets Access-Control-Allow-Origin: *, which sounds permissive — but a browser extension's content script is not a web page. Depending on where you issue the fetch from, you may hit mixed-content rules, or the request may go out with the page's origin rather than your extension's.

The reliable pattern is to never fetch from a content script at all. Do it in the service worker (or background page), where you can use the extension's host permissions to talk to 127.0.0.1 directly:

{
  "host_permissions": ["http://127.0.0.1:8765/*"]
}

Then the content script just passes card data over chrome.runtime.sendMessage, and the worker makes the call. One message channel, one place where networking happens, no CORS surprises.

Duplicates: the problem import never solves

The silent killer of generated decks is the second run. User converts chapter 3, imports, studies. Two weeks later they re-run it with better settings — and now every card exists twice, because a file has no idea what is already in the collection.

AnkiConnect gives you the pieces to fix this, but you have to assemble them. The two calls that matter:

findNotes with a query like "deck:Lectures", which returns note ids you can then fetch with notesInfo
canAddNotes, which takes a batch of note payloads and tells you which ones would be duplicates of existing notes

The cheap and effective approach: hash the normalized front text (lowercase, whitespace-collapsed) and keep the hash in a dedicated field or tag. Before writing, check canAddNotes and skip anything already present. AnkiMate does exactly this — re-running the same source updates instead of duplicating, which is the difference between a deck people keep and a deck they quietly abandon.

Things that bite in production

Desktop Anki must be running. This is the whole trade-off of the direct-write approach, and you should say it plainly in your UI instead of letting users discover it through a failed fetch. A graceful "Anki isn't open" state converts better than a console error.

Deck and model names are user-defined. Never hardcode "Basic" — fetch modelNames and deckNames on connect, and let the user pick. A card written to a nonexistent model fails silently in some versions.

Port 8765 is configurable. Users who run other tooling occasionally change it. Persist the port in settings and fail loudly with instructions rather than retrying forever.

The local server is trust boundary. Anything on the user's machine can talk to it, which is why AnkiConnect ships with a webApiKey option. If your extension runs in a shared-machine context, support the key.

Why this matters beyond extensions

The same pattern works for any local tool that wants to talk to Anki: scripts, editors, note apps. The export-file workflow made sense when Anki was closed; with a local API, "generate then import" is a choice, not a requirement. The users who care most — medical students, language learners, anyone with a deck they actually maintain — notice the difference immediately, because the file step is where their workflow used to break.

This is the integration behind AnkiMate, a browser extension that turns web pages, PDFs and YouTube transcripts into Anki cards and writes them in over AnkiConnect. It runs three generations a day free; writing to Anki is unlimited free. Disclosure: I built it — the architecture above is the real one, not the brochure version.

I shipped my extension in 9 languages to two stores. Here's what broke.

GlenKit — Wed, 04 Nov 2026 12:30:44 +0000

I shipped the same extension update to the Microsoft Edge Add-ons store and the Chrome Web Store in nine languages last week. The code change was maybe forty lines. The listing work took two days and broke in three different ways.

If you're about to localize a browser extension, here's what the consoles do not warn you about.

Why bother localizing at all

When you have no audience, store search is the only distribution channel you get for free. A monolingual listing only competes in English — the most crowded query space in both stores. A localized listing competes in a much thinner pool, because most indie extensions never translate anything.

That's the whole argument. It is not about "global reach". It's about being one of four results instead of one of four hundred.

Gotcha 1: every locale has its own character limit, and one of them is brutal

In Edge Add-ons, the short description stored in your manifest (extDescription) is capped at 132 characters — per locale, and it's a hard package-level validation, not a warning. I had five of nine locales over the limit and did not find out until the upload refused the package.

German and Russian blew past it almost immediately, because the same sentence is simply longer in those languages. "Summarize any page with your own AI key" is 41 characters in English and comfortably over budget once translated with any precision.

The fix is unglamorous: write the translation, then cut it to fit, then accept that the German short description is going to be a slightly different sentence than the English one. Don't translate; rewrite for the constraint.

The long description has a floor as well as a ceiling — 250 to 2000 characters. A too-short translation fails validation just like a too-long one, which is easy to hit in languages where you are being terse.

Gotcha 2: search terms are a budget, not a field

Edge gives you up to 7 search terms per language, and caps you at 21 unique terms across the whole listing. Not 21 per language — 21 total, deduplicated across all nine.

That means the term you use in English ("cookie banner") and the term you use in German ("Cookie-Banner") count separately, but repeating "cookie" in six languages does not give you six shots at it. Two of my listings blew the global budget — 23 and 22 terms — because I had been treating each language as an independent listing.

Plan the term set once, in a spreadsheet, before you touch the console. The console will let you type the eighth term and only complain at submit time.

Gotcha 3: the language dropdown is asynchronous and it will silently eat your work

This one cost me an entire product's listing.

In the Chrome Web Store dev console, the "edit language" control is a custom dropdown that loads its options asynchronously. If you switch language and start typing into the description field within a second or two, you are still writing into the previous language's field. Nothing visually indicates this. The field looks empty because it re-renders, and your input lands wherever the model currently points.

The result: every locale ended up holding the text of its neighbour. English field held German, German held Russian, and so on down the list. The store accepted it without complaint, because each field was a valid description of the right length.

Two rules came out of that:

After switching, poll the page until the visible "currently editing language" indicator actually names the language you asked for. Do not rely on a fixed sleep.
Verify by reading the saved text back, per locale, with a page refresh between switches. One page load can reliably switch language once; a second switch in the same load is where it goes wrong.

Read-back verification is the only thing that caught this. A screenshot would not have.

Gotcha 4: naming other companies' products gets you rejected for keyword spam

My first submission was rejected by an automated check within ten minutes.

The cause was a sentence in the description listing the consent-management platforms the extension supports — eight third-party trademarks in a row. To a human that reads as a feature list. To the automated reviewer it reads as keyword stuffing.

I rewrote it as a capability statement — what the extension does to a banner, not whose banner it is — and it went through. The same wording problem had already burned me once on a different product and a different store, so this is a pattern, not bad luck:

Describe what your software does. Do not enumerate other companies' names to prove coverage.

Gotcha 5: in Edge, editing the Properties page saves a draft and nothing else

The Partner Center has a page where you can edit your listing properties. Editing there and hitting save does not publish anything. The change sits as a draft until you walk the full update flow — Properties, then Privacy, then Listings, then Publish, then Submit — and the certification notes field must be filled or the submit is blocked.

Also, re-rendering between steps clears fields you already filled. In my case the certification notes textarea was wiped by clicking a radio button after typing. Fill the free-text explanation last.

The verification loop that actually works

After all of that, the process I'd keep is:

Precheck locally. Character counts, term counts, and a scan for third-party brand names — all checkable before upload, none checkable after rejection.
Fill one language at a time, confirming the active language before typing.
Read back every field, refreshing between languages, and diff against your source text.
Publish last, and treat any field with free text as something that may be cleared by the next click.

None of this is interesting engineering. It's just the difference between shipping in two days and shipping in two weeks.

I build small, privacy-first browser extensions — everything runs locally, and when an AI feature needs a model you bring your own key. If the workflow above saved you a rejection, the extensions are at glenkit.com.

Chrome Web Store rejected my extension in 10 minutes — the line that caused it

GlenKit — Mon, 02 Nov 2026 04:26:10 +0000

I had spent two weeks on a browser extension. The package passed the validation, the screenshots were ready, the privacy policy was written. I hit submit at 9 pm and went to make tea.

Ten minutes later the email arrived: rejected — "keyword spam in the description".

Not a code problem. Not a permissions problem. A copywriting problem, caught by an automated reviewer before any human ever looked at it.

Here is exactly what I did wrong, because it is a mistake almost every indie extension developer makes, and the fix takes five minutes.

What the rejected description looked like

The extension is a cookie-banner tool. I wanted the listing to be searchable, so I wrote a description that listed every consent platform the extension supports:

Automatically rejects cookie banners on OneTrust, Cookiebot, Quantcast, Didomi, Usercentrics, Iubenda, Sourcepoint, TrustArc and more...

Eight product names in a single sentence. It reads like a feature list. To a search engine it looks like keyword stuffing. To the reviewer's classifier it looks like exactly what it was: an attempt to rank for other companies' brand names.

The rejection reason was not vague either. It did not say "your extension may violate policy." It named the section and the violation type: keyword spam in the description. And it happened in under ten minutes, which tells you the first pass is purely automated — embedding similarity against known spam patterns, plus a brand-name frequency check.

Why this is such an easy mistake

Because listing integrations feels honest and useful. If your tool works with twelve platforms, saying so is not a lie. And in a README, listing dependencies is normal practice.

But the store listing is not documentation. It is an ad, and the ad has a search index behind it. When your description contains eight well-known competitor-ish brand names, you are not describing compatibility — you are bidding on their traffic, and the store knows it.

There is a second-order problem nobody talks about: the brand names do not help you anyway. Someone searching "OneTrust cookie banner" wants OneTrust's documentation. Someone searching "auto reject cookie banners" is your actual buyer, and that phrase is nowhere in the list of brand names.

The rewrite

I deleted every brand name and described the capability instead:

CookieGuard recognises the consent platforms most sites run on rather than a list of individual domains, plus a text-matching fallback that reads the banner in 35 languages.

Same information about coverage. Zero third-party trademarks. It passed on resubmission.

Note what changed structurally: the original sentence was a list of nouns, and the rewrite is a description of behaviour. That is the pattern worth remembering — describe what the software does, not who it interoperates with.

If you genuinely need to name a third party, say "works with major consent platforms" and put the specifics in your own documentation, where no store classifier is reading them.

Three more rejection triggers I hit later

The keyword-spam one was the most expensive, but not the only one. While shipping the rest of the portfolio, the same automated reviewer and the package validator produced three more:

1. extDescription has a hard 132-character limit in the package manifest. Not the store listing — the manifest field, which gets validated at upload. I had a description at 148 characters in six locales and it failed with a message about a field "conversion being too long" in a locale I was not even looking at. Fix: count characters per locale, not per language, and remember that accents and non-Latin scripts count as one character each in the JSON but may render differently.

2. Naming another browser in a localized description triggers a warning. When you submit to Microsoft Edge, writing "works in Chrome" in a German or Japanese description gets flagged as referencing a competing browser. I had to rewrite eight locales to say "the browser's built-in model" instead of naming anything. It is a fair rule and it is easy to trip if you translate from an English original that mentions Chrome naturally.

3. Search terms have a hard cap, and it is per locale. Seven terms per language, twenty-one unique terms total across the whole listing. I exceeded it by two words in Russian and one in French and the form simply refused to save. Nobody tells you this in the UI until you hit it.

What I would do differently

If I were starting the listing today, the checklist would be four lines:

Write the description with zero third-party proper nouns. If you catch yourself typing a brand name, replace it with what it does for the user.
Count the manifest description per locale before packaging. 132 characters, hard limit, validated at upload.
Never name another browser in a localized field. Say "your browser" and move on.
Budget your search terms before writing them. They are a scarce resource, not a wishlist.

The uncomfortable part is that all four are copywriting constraints, not engineering ones. I had unit tests for the rejection logic and none for the listing text, because I thought of the listing as packaging rather than as part of the product. Store reviewers disagreed.

The thing that still surprises me

The rejection was, in the end, a good outcome. The rewritten description converts better than the original, because it explains the tool instead of name-dropping. The version that tried hardest to be found for other companies' keywords was also the version that told the fewest people what the product actually does.

If you are waiting on a review right now and you listed a bunch of platform names in your description — that is probably why. You can edit the copy without resubmitting the package, and the fix is usually a five-minute rewrite.

I build small privacy-first extensions at GlenKit. The cookie tool mentioned above is CookieGuard — the description in this post is the one that finally shipped.

Hiding a cookie banner is not consent — what actually happens when you click "Reject all"

GlenKit — Tue, 27 Oct 2026 07:29:44 +0000

Most banner blockers do the same thing: they hide the banner with CSS and call it a day. The banner is gone from your screen — but nothing was ever told to the site. The tracking scripts you were shown a choice about? They load anyway. You got the appearance of consent without the mechanism.

I spent the last few months building a browser extension that takes the other approach: instead of hiding banners, it presses the real "Reject all" button — or calls the consent platform's own API when one exists. Here's what I learned about how consent actually works under the hood, and why "hiding" and "rejecting" are legally very different things.

What "Reject all" actually triggers

When you click a real reject button, one of several things happens depending on the consent management platform (CMP) the site uses:

A consent cookie gets written with an explicit deny state. The site's tag manager reads it on every subsequent page load and withholds non-essential scripts.
A JavaScript API is called — most major CMPs expose an API of their own, which propagates into an event that third-party scripts listen for.
In some setups, a server-side endpoint is hit to log the opt-out.

The point: rejection is a state change, visible to the site and to every script that respects the framework. Hiding the banner is a visual change, visible only to you.

The long tail is the hard part

The big consent platforms are easy — each has documented APIs and stable DOM structures. A couple dozen platforms by name covers a huge share of the web.

The long tail is everything else: regional CMPs, self-hosted script snippets, and sites that roll their own banner. For those, the extension ships a text-matching fallback that recognizes reject-style buttons across 35 languages — because "Refuser tout", "Alle ablehnen" and "拒绝全部" all mean the same thing, and your blocker should speak all of them.

It also sends the Global Privacy Control (GPC) signal on every page, which several US state laws now treat as a binding opt-out.

One more detail that matters: after clicking, the extension verifies the banner is actually gone — because a click that silently failed is worse than no click: you think you opted out, and you didn't.

Why not just block everything?

Because that breaks sites, and because it's not what you asked for. A real consent framework gives you a choice; the respectful default is the one privacy law actually contemplates: non-essential tracking off, site functional, zero data sent anywhere.

That last part is the design constraint I'm proudest of: the extension itself is 100% local. No account, no analytics, no telemetry. It stores exactly two things per site — the hostname and your choice — and you can wipe it anytime.

Try it

CookieGuard runs on Chrome and Edge. The free tier gives you 40 successful rejections a week with every detection feature enabled; Pro ($19.9 lifetime or $11.99/year) lifts the cap and adds per-site defaults.

Site: glenkit.com/cookieguard
Edge Add-ons store: CookieGuard

We're also launching on Product Hunt — if you've ever wondered whether your "Reject all" click actually did anything, it's a fun rabbit hole.

Happy to answer questions about consent-platform internals in the comments — it's a weirder ecosystem than you'd expect.

Your screenshot tool is the leak — doing redaction entirely client-side

GlenKit — Fri, 16 Oct 2026 08:23:32 +0000

The most common way people redact a screenshot is still this:

Take the screenshot.
Search "blur image online".
Upload it to the first result.
Blur the part that matters, download, paste into Slack.

Step 3 is the problem. You just handed an unredacted screenshot — session tokens, customer emails, API keys, production data — to a website you found ninety seconds ago. The blur happens after the upload, and the "delete" button on that page deletes your copy, not theirs.

It's a small, boring leak, and it happens thousands of times a day, because the tool that solves the aesthetic problem (make this text unreadable) creates a security problem (it made a copy first).

The rule I'd propose

Redaction must happen on the machine the screenshot was taken on, before the image goes anywhere. If the pixels reaching any network request are already covered, the rest of the pipeline stops mattering — you can paste it into a chat, a ticket, a bug report, and the sensitive part isn't in the file.

That's the whole design constraint. Everything below falls out of taking it seriously.

Anatomy of a leak, in the browser

A screenshot in a browser is a compositor output. The extension API is chrome.tabs.captureVisibleTab, which returns a data URL of the visible viewport:

const dataUrl = await chrome.tabs.captureVisibleTab({ format: 'png' });

At this point you hold a faithful copy of everything on screen, including the parts nobody wants in a public issue: the token in the address bar, the Authorization header value in some debug panel, the customer list scrolled halfway down.

The naive version of a redaction feature is a UI on top of that image. The important version redacts before you decide to keep the file — i.e. the extension should never write the raw capture anywhere durable.

What "covered" should actually mean

Two choices worth being deliberate about:

Blur vs solid fill. Blur looks more polite, but for text it's a lossy encoding, not a one-way function. Low-radius blurs of high-contrast text (a monospace token on a dark terminal, for instance) have been reconstructed with deconvolution, and text heights are highly constrained, which shrinks the search space. For secrets, use an opaque fill. Blur is for faces and plates, where the content is continuous, not discrete.

Redraw vs overlay. Overlaying a rectangle in an HTML layer is easy and completely useless — the underlying pixels are still in the export. You need to composite (draw the image, then draw the fill on top) and export the re-encoded result:

const off = new OffscreenCanvas(w, h);
const ctx = off.getContext('2d');
ctx.drawImage(imgBitmap, 0, 0);                 // the capture
ctx.fillStyle = '#111';
ctx.fillRect(x, y, w0, h0);                     // irreversible at this point
const blob = await off.convertToBlob({ type: 'image/png' });

Everything downstream operates on that blob. If a cover is wrong, the user redraws; there is no "uncover" and no original in the payload.

The part that actually reduces user error: pre-detection

Manual redaction fails the same way manual everything fails — people miss one spot, usually the boring one. So the useful feature isn't a nicer brush; it's candidate detection before the user looks:

DOM-matched regions. Elements with type="password", autocomplete="cc-number", inputmode="numeric", or a name/id matching /token|secret|api[-_]?key|otp|ssn/i. The element's bounding box maps directly to image coordinates via getBoundingClientRect() plus scroll offsets.
Text-pattern regions. Run a small regex set over the visible text nodes and highlight matches: JWT shape (eyJ[A-Za-z0-9_-]{10,}\.), sk-/ghp_/AKIA prefixes, IBAN-ish and card-number-ish digit runs, private-key headers.
Structural guesses. Terminal/console panes, .env-looking blocks, admin tables — worth flagging, not auto-covering.

The output should be a proposed set of covers the user can delete in one click. Auto-covering without review is its own failure mode: over-covering quietly destroys the screenshot's purpose, and the user then posts a useless image or, worse, turns the feature off.

Where detection honestly fails

I'd rather list the limits than imply a guarantee:

Canvas / WebGL / video. If the secret is rendered into a canvas or a <video> frame, there is no DOM node and no text node. Regex detection sees nothing. Only a manual cover catches these.
Images of text. A screenshot of a screenshot, a scanned invoice, a chart with labelled series. No OCR, no detection.
Anything virtualised. Table cells recycled by a virtual list can be measured before or after they exist in the DOM, depending on scroll timing. Off-by-one-row covers are a real bug class.
Shadow DOM. Closed shadow roots are invisible to the traversal; you get a bounding box with no children to inspect.

So the honest product claim is "detection reduces misses; the manual cover is still the guarantee." Any tool claiming otherwise is describing a best case.

What this means for the architecture

Client-side redaction has one more consequence, and it's the reason I'd pick this shape again: there's nothing to operate. No upload endpoint, no object storage, no retention policy to write, no "we delete after 24h" claim to make and be audited on. The security property is structural rather than promised.

For a small tool that's the difference between a feature you can ship and a small compliance project. The trade is that you can't do the heavy stuff on a server — no models, no OCR on the secret-detection step, no history sync. In exchange, the failure mode of your infrastructure is "nothing happens," which is the failure mode I want.

I built this into a small extension — Veilshot. Pricing, stated plainly: the free tier does the manual covers (no account, no network requests at all — that's checked in CI on every build, not just promised in a policy); Pro is a one-off $19 for pattern detection, keyword rules and per-site rules, no subscription. It's a paid product and I'm not going to pretend otherwise. But the pattern is the more useful takeaway, and it generalises well past screenshots: if the data is sensitive, transform it before it moves, not after. Blur tools on the web got the order wrong, and that's the entire bug.

Turning what you read into Anki cards without the typing

GlenKit — Tue, 13 Oct 2026 04:12:21 +0000

Turning what you read into Anki cards without the typing

Here's a workflow that fails quietly, every day, for a lot of people:

You read something good — a paper, a lecture PDF, a long article, a YouTube lecture.
You think "this belongs in Anki."
You open Anki, create a deck, and start typing cards by hand.
You make six cards, it's been twenty minutes, and you close the window.

The material never makes it in. Not because spaced repetition doesn't work — it obviously does — but because the input step is manual while the review step is automated. Anki's scheduler is a piece of software. Your card creation is you, typing.

The bottleneck is card creation, not review

Most "I fell off Anki" stories I've heard are really "I stopped making cards" stories. Reviewing thirty cards takes a few minutes and has an algorithm pushing you along. Writing thirty cards takes an hour of undifferentiated typing, and nothing pushes you along at all.

That asymmetry is worth naming, because it tells you where a tool can actually help. Nobody needs help being nagged to review. What's missing is a low-friction path from "the thing I just read" to "a card in my deck."

Three ways to close the gap — and what each one costs

If you look at how people have tried to solve this, there are basically three shapes.

CSV / export pipelines. Generate cards somewhere, export to a file, import into Anki. This works, and it's the most common DIY approach. The costs show up later: field mapping breaks when your template changes, the import dialog steals focus, and there's no deduplication — run it twice on the same article and you get two copies of every card. In a deck you'll keep for years, duplicate cards are worse than missing cards, because they double your review load silently.

Anki add-ons. Running inside Anki is convenient if that's where you already are. But by definition an add-on starts after the text exists somewhere — it can't see the PDF you have open in a browser tab, and it can't see the article you're reading. It also only runs on desktop Anki, and it breaks on Anki version bumps.

A browser extension. This is the shape I ended up building. The argument for it: the content arrives in the browser first — pages, PDFs, YouTube transcripts. If you intercept it there, you're working at the actual point of friction, and you don't need the user to leave what they're doing to go make cards.

Writing through AnkiConnect instead of exporting files

The technical decision that mattered most was to write cards into the collection through AnkiConnect rather than generating an import file.

AnkiConnect is a local HTTP server exposed by an Anki add-on (code 2055492159, free). Because it can query the collection, you can do two things a file export fundamentally cannot:

// ask the collection what already exists before writing
{ action: "findNotes", version: 6, params: { query: 'deck:"Reading" "{{text}}"' } }

// then write only the notes that aren't there yet
{ action: "addNotes", version: 6, params: { notes: [...] } }

The first call is the interesting one. A dedupe check against the live collection turns "generate 40 cards" into "generate 40 cards, 12 of which you already have" — and the second group never gets written. It also means cards land with the right note type and tags, in the deck you chose, with no import dialog and no field remapping.

The honest cost of this approach: it requires desktop Anki running locally. That's a real constraint — no AnkiWeb-only setup, no mobile. I took the trade because a card that lands in the wrong deck with the wrong template isn't really a card.

On-device inference, or your own key

The second decision was where inference runs. The default is Chrome's built-in on-device model, which means the selected text never leaves the machine — no upload, no account, no telemetry. If you want a stronger model, you paste your own API key (OpenAI / Anthropic / Google) and the request goes browser → provider directly.

Two things fall out of that architecture, and I'd rather state them plainly than let them be discovered later:

Because inference runs on the user's machine or the user's key, there's no per-generation cost sitting on a server of mine. That's why a one-time price is possible instead of a subscription — not a marketing stance.
The only outbound request the extension makes is license activation. Nothing in the pipeline requires a server I operate.

What generation gets wrong (and why "prune" is the real feature)

LLMs will happily produce forty mediocre cards from a page of prose. Forty mediocre cards are worse than twelve good ones: they're more review load, lower retention per minute, and they train you to skim.

So the workflow the tool is built around is generate → prune → write, not generate-and-accept. Cards come back in a side panel where you edit or delete them before any of them touch the collection. The list-splitting template exists for the same reason: an enumeration in the source ("five causes of X") is a place where one card per item beats one card asking for all five.

If there's one habit I'd recommend regardless of tooling: cap what you write per reading session. Twenty cards from an article you understood beats eighty from an article you skimmed.

Full disclosure, and a question

I'm the developer of AnkiMate — a Chrome/Edge extension that does the above. Pricing, stated plainly: free tier is 3 generations a day and writing cards into Anki is always free and unlimited; Pro is $19.9 one-time (Cloze, batch generation, future templates), no subscription. It's a paid product and I'm not going to pretend otherwise.

I'm not claiming it's better than what you use — I don't have the user base to make that claim honestly. What I'd genuinely like to know is where your own pipeline breaks:

Is the friction in capturing the source, in generating the cards, or in the pruning/editing step afterwards?

My assumption while building was that pruning is the part people underrate. If you're a heavy Cloze user and that assumption is wrong, I'd rather find out now.

Why most cookie-banner blockers don't actually work

GlenKit — Thu, 08 Oct 2026 14:58:51 +0000

Why most cookie-banner blockers don't actually work

Install a typical cookie-banner blocker, then watch the network tab while you visit a site. Here is what actually happens:

The page loads. The consent management platform (CMP) script executes and builds the banner.
The blocker's CSS sets display: none on the banner element.
The banner disappears from your screen.
The CMP never receives a "reject" signal. Non-essential scripts keep loading exactly as before.

That fourth step is the part almost nobody talks about.

Hiding is a cosmetic operation

A cookie banner is not a decorative overlay you're allowed to delete. It's the UI of a consent platform — a script that is supposed to record a decision and hand that decision to the tag manager, which then decides whether to fire analytics, ads, session replay, and so on.

If you remove the banner with CSS, you have removed the UI and left the machinery untouched. The page has no idea what you wanted, so it defaults to its own default, which is usually "everything on until told otherwise."

The visible result is identical. The legal and technical result is the opposite of what the user intended.

What a real opt-out actually requires

Consent platforms are designed to accept a decision from a few specific entry points. To genuinely reject, a tool has to use one of them:

Trigger the platform's own reject control — the same element a human would click, selected per platform (#onetrust-reject-all-handler, [data-testid="reject-all"], button[aria-label*="reject"], …). It has to be the actual control, not a look-alike button the tool injects.
Call the platform's public API, e.g. OneTrust's OneTrust.RejectAll(), or Cookiebot's consent submit methods. These write the consent record that the tag manager reads.
Post a proper TCF v2 string for IAB-compliant platforms, so downstream vendors see a "no consent for purposes 1–10" state.

There is a reason most blockers skip this: it's platform-specific, the DOM changes constantly, and each CMP has its own naming. A CSS rule works on every site forever. An API call breaks next Tuesday. So the ecosystem settled on the version that's easy to maintain instead of the one that works.

The signal almost nobody sends: GPC

Global Privacy Control is a legally recognised opt-out preference signal under the CCPA/CPRA and several US state privacy laws. It has two parts:

1. A request header, Sec-GPC: 1 — trivial to add from an MV3 extension via a declarative rule:

{
  "id": 1,
  "priority": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [
      { "header": "Sec-GPC", "operation": "set", "value": "1" }
    ]
  },
  "condition": {
    "urlFilter": "*",
    "resourceTypes": ["main_frame", "sub_frame"]
  }
}

2. The JS property navigator.globalPrivacyControl, which sites can read directly. Chrome doesn't ship it (yet), so an extension has to define it in a content script running before page scripts:

try {
  Object.defineProperty(navigator, "globalPrivacyControl", {
    get: () => true,
    configurable: false
  });
} catch (e) { /* already defined */ }

Because it's a legal signal in some jurisdictions, a site that receives it is supposed to stop selling or sharing your data even without a banner interaction. Yet a quick audit of the popular CSS-hiding blockers shows most of them never send it. Hiding a banner is easy to demo; sending a header that no screenshot can show isn't.

Why this category went stale

Here's the part that made me actually build something.

The extension with the largest install base in this category was acquired a few years ago and — as of this writing — has not shipped an update since mid-2024. The store reviews have shifted accordingly: a large share of the nearly 1,900 ratings are now one star, and the top-voted comments read like "stopped working on many sites" and "breaks scrolling". Meanwhile a community fork that just keeps the rules updated has picked up a couple hundred thousand users.

That tells you two things:

Users in this category do switch tools — the switching cost people assume exists isn't really there.
The category's problem is maintenance, not novelty. Consent platforms change their DOM; a blocker that isn't updated decays into "hides some banners, silently fails on others."

The three constraints I built around

Full disclosure: I'm the developer of a blocker in this space, CookieGuard. I'm not going to claim it's "better" — I have too few users to make that claim honestly. What I can describe is the shape of the problem I constrained myself to, because each constraint comes straight from what the reviews complain about:

Press the real button. Identifies the CMP by name (27 of them), triggers its genuine reject action or calls its own API; unknown banners fall back to a phrase library (224 don't-sell phrases across 35 languages); verifies the banner is actually gone rather than assuming.
Don't break the page. The rejection is scoped to the banner it dismissed. No page rewriting, and it never clicks "Accept" on your behalf — a consent tool that accepts on your behalf is worse than no tool.
Nothing leaves the machine. No account, no analytics, no telemetry. The optional per-site memory stores a hostname and the action you took, and clears in one click.

It's a manifest V3 extension, rules ship as a versioned JSON file (because that's the part that has to stay current), and the only outbound requests it makes are an optional daily rules fetch and licence activation.

The question I'd actually like answered

Treat the tool as irrelevant to this post. The design question is:

Should a consent tool be judged by whether the opt-out legally registers, or is hiding the banner good enough?

If the answer is "hiding is fine," then the entire GPC layer and the CMP-specific API calls are wasted complexity, and the whole category can stay six lines of CSS. If the answer is "it should actually register," then most of the popular tools are shipping the cosmetic version of a legal feature — and that's worth saying out loud.

Either way: if you've hit banners that neither approach handles, the shape of the failure is more useful to me than a rating. Tell me what the site was and what happened.

From web page to Anki deck in one click: a flashcard workflow that stays in your browser

GlenKit — Wed, 30 Sep 2026 02:09:21 +0000

If you use Anki seriously, you already know the workflow: read an article, spot a fact worth remembering, switch windows, paste it into a note template, reformat it, repeat. The reading and the card-making happen in two different worlds, and the friction quietly kills half the cards you intended to make.

This post walks through a workflow that keeps everything in the browser tab: select text, generate flashcards, review them, and write them straight into your Anki decks. It uses AnkiMate, a Chrome and Edge extension my team built — but the setup (AnkiConnect + a capture habit) works with other tools too, so most of this post applies even if you use something else.

The 60-second setup

Install the AnkiMate extension (also on Edge).
In desktop Anki, install the AnkiConnect add-on (code 2055492159) and restart Anki.
That's it. The extension talks to your local Anki over AnkiConnect — there is no account, no cloud sync step, no middleman.

The workflow: select → generate → review → write

Select any text on an article, lecture note, or documentation page (or use full page / PDF / YouTube transcript as input).
Right-click → Generate flashcards. A side panel opens with draft cards.
Edit or delete anything you don't like. Nothing is final here — every card is editable, removable, and draft-saved.
Pick a deck and hit Write to Anki. Cards land in your collection tagged and deduplicated.

The last step is the one that saves the most time. Cards are written directly into the deck you choose, deduplicated by content hash — and if the source page changed, the card gets updated instead of duplicated. No more discovering three near-identical cards about the same fact a month later.

Templates tuned by subject, not one generic prompt

A generic "make flashcards from this text" prompt produces generic cards. AnkiMate ships nine templates, each tuned for a subject:

Medicine (USMLE) — expects clinical detail, not trivia
GRE vocabulary — word, definition, usage
Language learning — front/back with context, plus a reversed-vocabulary variant
Law — element-based structure
Programming — concept and code-focused cards
List breakdown — turns enumerations into atomic cards (the classic "one fact per card" rule, enforced for you)
General — everything else

Eight templates are free. Pro adds Cloze deletions (fill-in-the-blank), which is the right format for definitions, dates, and anatomy.

Privacy: on-device AI by default, BYOK if you want more

This matters to us, so it's the design center: on-device AI handles generation by default, and your selected text never leaves the browser. If you want a stronger cloud model, you plug in your own API key — and then your text goes directly from the extension to that provider, not through our servers. We never see your selections, your cards, or your key. (We wrote up why this matters in more detail — most "AI readers" proxy every page you visit through their own backend.)

Pricing, honestly

Free, every day, no card required: 3 generations per day (roughly 45–90 cards), all 8 non-Pro templates, all input types, unlimited writes to Anki. For most students this is genuinely enough.
Pro · Lifetime $19.9 (launch price, $29.9 after): unlimited generations, batch generation of 20+ cards from long pages, and the Cloze template. One payment, no subscription — the price of two coffees for the tool you'll use every study session.

Honest limitations

Desktop Anki (with AnkiConnect) needs to be running when you write cards — AnkiMobile/AnkiDroid alone won't receive them.
Generation quality tracks source quality: a well-structured page produces great cards; a rambling forum thread needs more editing.
It makes cards, not understanding. Spaced repetition still requires you to actually do the reviews.

Try it

Install from the Chrome Web Store or Edge Add-ons, or read more at glenkit.com/ankimate. If you have questions about the AnkiConnect setup or template design, leave a comment — I reply to all of them.

How to summarize 2-hour videos and 50-page articles without leaving the browser tab

GlenKit — Tue, 29 Sep 2026 07:39:22 +0000

A 40-minute conference talk. A 90-minute podcast. A 12-minute tutorial that could have been a blog post. Most of what's valuable in a video is its content — and content can be read.

I've been building GlenSum, a browser extension that summarizes long videos and articles directly in the tab. This post covers the three working approaches to media summarization in a browser, the privacy trade-off most people don't notice they're making, and what "long content" actually means for an LLM.

Three ways to summarize a YouTube video (slowest to fastest)

1. The transcript, by hand

Every video with captions has a transcript: expand the description → Show transcript → select all → paste into any AI chat.

Cost: free
Time: 3–5 minutes of fiddly copying, and raw transcripts are messy — no punctuation, no speaker labels, timestamps everywhere
Best for: one-off use when you can't install anything

2. Paste the URL into an AI chat

Some assistants accept a YouTube URL directly and fetch the transcript themselves. Paste the link, ask for key points.

Cost: often limited by your plan's usage quota
Caveat: availability varies by model and region — and now the video passes through yet another service
Best for: occasional videos when you already pay for an assistant

3. A browser extension, one click

Extensions built for this read the transcript from the page you already have open and generate a structured summary in a side panel. The workflow becomes: open the video → click the extension → read the summary. No copying, no tab-switching.

The extras that matter: adjustable summary length, follow-up questions about the content ("what did they say about X?"), bilingual output when the talk isn't in your first language, and Markdown/PDF export so the summary lands in your notes.

The privacy trade-off most people miss

Here's the part that motivated building this in the first place. When you paste a URL or transcript into a hosted summarizer, your reading and watching history becomes someone's dataset. Article by article, video by video, a profile of what you consume accumulates on a server you don't control. That's a real cost that never shows up on the pricing page.

The alternative is BYOK — bring your own key:

You paste an API key from your own AI provider (OpenAI, Google, a local gateway, anything OpenAI-compatible) into the extension once.
The extension reads the page content in your browser and sends it directly to the provider you chose.
There is no middleman server. No account. No logs on my side, because there is no "my side" — the extension ships as static code, and the network calls go from your browser to your provider.

The trade-off is honest: you manage your own key, and free-tier users can still use built-in free models without one. But nobody in the middle ever sees what you read.

What "long" actually means for an LLM

Summarizing a 2-hour talk isn't just "paste transcript into prompt". A two-hour transcript is roughly 25,000–40,000 words — technically it may fit a modern context window, but quality degrades: the model skims, drops the middle, and blends sections together.

The approach that works is map-reduce over chunks:

Map: split the transcript (or article) into overlapping chunks at natural boundaries — chapters, speaker turns, section headings — and summarize each chunk separately.
Reduce: merge the chunk summaries into a final structured summary, keeping section-level detail instead of a mushy average.

This is also why page-native tools beat copy-paste: the extension already knows the page structure, so it can split at real boundaries instead of arbitrary token counts.

When a summary is the wrong tool

Summaries are ideal for inverted-pyramid content: talks, podcasts, news analysis, tutorials — where information density is low and predictable. They're poor substitutes for demonstration content: if someone is showing you how to do a three-point turn, no summary captures the steering.

A good rule: summarize first to decide whether to watch — not to avoid watching things worth watching.

Try it

GlenSum is free to install and works out of the box (built-in free models, or your own key for unlimited use):

🌐 Site & docs: glenkit.com/glensum
🧩 Edge Add-ons · Chrome Web Store

Questions about the architecture — especially around BYOK flows or chunking strategies for long transcripts — happy to answer in the comments.