DEV Community: GlenKit

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.