DEV Community: On Pounch Man

My Landing Page Has 50 Tests and None of Them Need a Browser

On Pounch Man — Sat, 10 Oct 2026 06:05:59 +0000

The landing page said the tool helps you prepare messages. Two edits later it said the tool reliably sends them. One more and it promised reliable delivery.

No check failed. No reviewer objected. The product simply started claiming something the code cannot guarantee, and nothing in the pipeline had an opinion about it.

That is the failure mode I actually have. Not a crash. A sentence that drifts away from what the code does, one reasonable commit at a time.

The suite that grew out of that worry is 50 tests across 14 files, and it finishes in 568ms:

$ node --test "tests/**/*.test.mjs"
# tests 50
# pass 50
# fail 0
# duration_ms 568.668334

No browser. No dev server. No build step. Here is what it covers, and where I think it is the wrong tool.

Browser APIs are injectable if you stop reaching for globals

Everything about storage in this app goes through one factory:

export function createWorkspaceStorage({
  indexedDB = globalThis.indexedDB,
  localStorage = globalThis.localStorage,
  now = Date.now,
  uuid = () => globalThis.crypto.randomUUID()
} = {}) {

Those defaults are the entire reason the storage layer is testable in Node. In tests I hand it fake-indexeddb, a Map pretending to be localStorage, and a frozen clock:

function fixture(initial = {}) {
  const entries = new Map(Object.entries(initial));
  const localStorage = {
    getItem: key => entries.get(key) ?? null,
    removeItem: key => entries.delete(key),
    setItem: (key, value) => entries.set(key, value)
  };
  const options = { indexedDB: new IDBFactory(), localStorage, now: () => clock };
  return { entries, localStorage, options, storage: createWorkspaceStorage(options) };
}

The Map is returned rather than hidden so a test can assert on raw keys, which is what makes the migration tests further down possible. sql.js is WebAssembly, so the SQLite session parser runs in Node with no shims at all.

One caveat: no DOM. Anything that only exists in a rendered component is not covered here and I am not pretending otherwise.

Test the shape of prose, never the sentences

I do not assert that my copy is good. I assert the properties that survive a rewrite.

const home = source('app/pages/index.vue');
assert.match(home, /class="faq-item"><h3><button/);
assert.match(home, /<th scope="col">/);
assert.match(home, /<th scope="row">/);
assert.match(home, /<cite><a/);
assert.match(home, /<time datetime="2026-10-08">/);

Four things are pinned here and none of them is a word choice.

<h3><button> means the FAQ is a real disclosure widget. A div with a click handler looks identical on screen and is invisible to a keyboard, a screen reader, and most crawlers. That mistake is easy to make and easy to miss in review.

scope on the headers means the comparison table parses as a table.

<cite> next to an https://telegram.org/faq_spam link means claims about Telegram's own policy point at Telegram rather than at a blog post that paraphrased it. One test is stricter than that:

assert.ok(locale.sources.every(source => source.url.startsWith('https://telegram.org/')));

Every reference in every article has to be a primary source. Wanting to cite a third party therefore requires changing the test, which is the conversation I want to be forced into.

<time datetime="2026-10-08"> means the page carries the date it was last verified. That date decides whether the page is trustworthy in a year, and it is also the easiest thing in the world to forget.

Bilingual parity is a contract you can execute

English is the source language. Chinese gets written after, usually days later, sometimes without me rereading the English.

assert.equal(detail.en.sections.length, detail.zh.sections.length);
assert.ok(locale.sections.length >= 5);
assert.ok(locale.sections.some(section => section.table));
assert.ok(locale.sections.some(section => section.list));
assert.ok(locale.coverAlt.length > 15);

I cannot proofread Chinese at the speed I write English, so I stopped verifying words and started verifying shape. Section counts match. Every article has a table and a list, which stops one language from getting an article that reads as a wall of text. Cover alt text is long enough to describe something.

There is also a test whose only job is keeping one bad phrase from coming back:

assert.ok(!home.toLowerCase().includes('telegram message send,'));

Ugly. It has been in the repo for months.

Assert document order, not just presence

The homepage makes an argument in sequence. What the tool is, how a campaign runs, what to do when it breaks, then the questions people ask before they trust it. Reorder those blocks and the page still renders, still looks fine, and still passes any test that only checks for presence.

assert.ok(home.indexOf('workflow-section') < home.indexOf('<FeatureStories'));
assert.ok(home.indexOf('<FeatureStories') < home.indexOf('class="faq section'));

Ordering assertions are cheap and they encode intent that no linter and no type system will ever know about.

I also count data entries with regex, which I recommend with a caveat:

assert.equal((articles.match(/sections: \[\s*\n/g) || []).length, 6);
assert.equal(stories.split("kind: 'compose'").length - 1, 2);

The second line says each of three stories appears exactly twice, once per language. It works, and it will break the day someone reformats that file.

The analytics boundary is the most tested thing in the repo

Seven of the fifty tests exist because analytics is the only path by which user data can leave the machine.

The whole boundary is one function and one allowlist:

const schema = {
  account_login: { outcome: ['success', 'failed', 'password_required'] },
  session_import: { outcome: ['success', 'partial', 'failed'] },
  campaign_complete: { outcome: ['success', 'partial', 'failed'] }
  // ...
};

export function safeAnalyticsEvent(name, parameters = {}) {
  if (!Object.hasOwn(schema, name)) return null;
  const result = {};
  for (const [key, allowed] of Object.entries(schema[name])) {
    if (allowed.includes(parameters[key])) result[key] = parameters[key];
  }
  return result;
}

Event names that are not in the schema are dropped entirely, and so is every parameter that is not listed for that event. A parameter whose value is not one of the enumerated strings never makes it out either, which is what makes free text structurally unable to be recorded.

The test that carries the weight asserts on the entire output rather than the absence of one field:

assert.deepEqual(
  safeAnalyticsEvent('account_login', {
    outcome: 'success',
    phone: '+123',
    password: 'private',
    session: 'private',
    error: 'private'
  }),
  { outcome: 'success' }
);

Written this way it fails if anyone adds a field later, including a field I might approve of. Blocklists leak things nobody thought of. A snapshot of the allowed output does not.

The same shape applies to page paths and clicks:

analyticsPage('/zh/guide?phone=123#code')                    // { page_path: '/zh/guide', ... }
analyticsPage('/user/private-phone')                         // { page_path: '/404', ... }
classifyAnalyticsLink('javascript:alert(1)', origin)         // null
classifyAnalyticsLink('https://t.me/private-user', origin)   // null

A phone number that ends up in a URL cannot reach the analytics provider, because the path is matched against a fixed list and everything else becomes /404. Click events never carry an href. They carry a destination label assigned by code, and a link whose target is not one of the known ones reports nothing at all.

The test that lints my future code

Unit tests check code that exists. The failure I was worried about lives in code I have not written yet, at a call site that goes around the safe function.

const workspace = readFileSync(new URL('../app/components/OnlineWorkspace.vue', import.meta.url), 'utf8');
for (const call of workspace.matchAll(/track\([^;\n]+/g)) {
  assert.ok(!/phone\.value|message\.value|file\.name|account\.id|account\.phone|cause\.message/.test(call[0]));
}

It walks every track() call and fails if any of them mentions message content, a phone number, an account id, a filename, or a raw error message. Crude regex, and it has already caught one call site I wrote on autopilot.

The analytics plugin gets checked for the settings that are easy to lose:

assert.match(plugin, /send_page_view: false/);
assert.match(plugin, /allow_google_signals: false/);
assert.match(plugin, /ad_user_data: 'denied'/);
assert.ok(!plugin.includes('document.referrer'));

send_page_view: false is deliberate. This is a client-routed app, so the built-in page view fires at the wrong moment and I fire it manually after navigation.

One assertion exists purely because of a race I hit while building the consent flow:

assert.ok(plugin.indexOf('localStorage.getItem(storageKey)') < plugin.indexOf('consentReady.value = true'));

Saved consent has to be read from storage before the app declares consent resolved. Get that order wrong and a returning visitor either sees the banner again, or gets measured before their stored choice is applied. No type catches this. Now a test does.

Migration tests where the interesting part is failure

Moving accounts and logs out of localStorage produced the three tests I would have written last if I had written them from the code. I wrote them from the failure modes instead.

The rule is commit first, delete second.

// initialize() writes to IndexedDB, then removes the legacy keys.
// Any failed write means nothing is removed and everything rolls back.
await assert.rejects(storage.initialize());
assert.equal(entries.size, 2);              // both legacy keys still present
localStorage.setItem('legacy.logs.v1', '[]');
const result = await storage.initialize();  // clean retry

Second, the case where the delete never succeeds. I replace removeItem with something that throws and run initialization twice:

localStorage.removeItem = () => { throw new Error('Storage denied'); };
assert.equal((await storage.initialize()).logs.length, 1);
assert.equal((await storage.initialize()).logs.length, 1);  // no duplicate

A migration that is not idempotent duplicates every record on each retry, so the user opens the page and finds their log twice. That bug ships quietly.

Third, boundaries, using the injected clock:

assert.equal(retainLogs([
  { time: clock - LOG_MAX_AGE },
  { time: clock - LOG_MAX_AGE - 1 },
  { time: NaN }
], clock).length, 1);

Exactly thirty days old is kept. One millisecond older is dropped. A record with an unparseable timestamp is dropped rather than sorted into some unpredictable position. Testing that without an injectable clock means waiting a month.

There is an atomicity test as well: saving an account that is missing its id rejects and leaves the previously stored accounts untouched. Accounts hold sessions, so a partial write there is not cosmetic.

Security regressions deserve names

The session importer reads a SQLite file the user downloaded from somewhere else, and that file contains the Telegram server address to connect to.

db.run('CREATE TABLE sessions (dc_id INTEGER, server_address TEXT, port INTEGER, auth_key BLOB)');
db.run('INSERT INTO sessions VALUES (?, ?, ?, ?)', [2, 'attacker.example', 80, key]);

assert.equal(parseSessionBytes(db.export(), SQL).serverAddress, '149.154.167.51');

The test builds a real database, plants a hostile endpoint in it, and asserts the parser throws the address away and dials the official one. If someone later simplifies the parser into trusting the file, this test fails and its name explains why.

The key in that test is a synthetic 256-byte array and the test file says so in a comment. A test that ships a real credential into a CI log is its own kind of bug.

The credential masking pair gets similar treatment:

const masked = maskTelegramApiHash(hash);
assert.equal(restoreTelegramApiHash(masked), hash);
assert.ok(!masked.includes(hash));
assert.notEqual(masked, maskTelegramApiHash(hash));  // fresh mask every call

for (const value of [undefined, null, '', 'bad', {}, 123]) {
  assert.equal(restoreTelegramApiHash(value), '');
}

Round trip works, the plaintext never appears as a substring of the output, and garbage input returns an empty string instead of throwing or echoing back what it received.

What this costs

String assertions against source files are brittle, and I want to name the specific places mine are.

This one slices a Vue component between two markers and asserts where a log reset lands relative to the calls around it:

const campaign = source.slice(source.indexOf('async function sendCampaign()'), source.indexOf('onMounted(async'));
const reset = campaign.indexOf('await storage.clearLogs(); logs.value = [];');
assert.ok(reset > campaign.indexOf('await client.connect()'));
assert.ok(reset < campaign.indexOf('await client.sendMessage'));

It breaks on a rename. It is also the only test I have that catches a bug class no unit test can see, because the bug is not in the storage layer and not in the send loop. It is in the order they are wired together, and that order is what a user experiences when the previous campaign's log appears at the top of the new one.

Same story for the indexOf ordering checks and for counting entries with regex. Tests that read .vue files can pass while the page is broken in a real browser. I accept that trade, because the failure I need to catch here is content that slowly stops being true, and that failure is invisible to a unit test no matter how well the layer underneath is factored.

My rule when writing these: assert what a reader, a crawler, or a keyboard can observe. Markup semantics, document order, cross-language parity, timestamp validity, and where user data stops moving. Skip anything I plan to refactor.

Where this code lives

Every assertion above belongs to TGSender, a free Telegram bulk message sender that runs entirely in the browser: TGSender. If you would rather not keep a tab open, there is a Chrome extension that runs the same code in the background.

One claim I am not going to write, and the suite is the reason: free does not mean unlimited sending. Telegram's own rate limits, permissions, and privacy settings all still apply, and the 30-second gap between messages is a number this tool chose rather than one Telegram endorses. Every sentence in that paragraph has something in the suite holding it up, so if I ever drift, something goes red.

The line I keep coming back to

If a claim is load-bearing for user safety, legal exposure, or accessibility, promote it from prose into a failing test.

Prose rots on its own. A failing test rots loudly.

I Built an AI Tarot Demo in Two Hours. Shipping the Product Was a Different Job.

On Pounch Man — Fri, 18 Sep 2026 09:59:28 +0000

My wife was interested in tarot cards, and I was a frontend developer looking for an excuse to build something. I put together a page with a deck, a card-flipping animation, and an AI-generated reading.

With AI assistance, the basic flow worked in about two hours.

I thought authentication and payments would get it ready to launch. Then the questions started: What happens when someone switches devices? What if a paid reading stops halfway through? Can I change a guided exercise without changing the meaning of someone’s saved answers?

Eventually, another question became harder than any of those: how do I get people to use it?

The project is now Mystic Journey. It includes a daily card ritual, guided explorations, a personal journal, and an optional companion board.

I’m still looking for early users. This is a development retrospective—and, openly, an invitation to try what I’ve built.

Why I changed the product

The original experience was straightforward: ask a question, draw cards, read the interpretation, leave.

But a general-purpose AI can already explain tarot cards. A nicer animation wasn’t enough to explain why someone should return to my website.

I started thinking about the experience around the reading. Writing in an empty journal can be surprisingly difficult. A card, a specific question, or a few choices might make it easier to begin reflecting.

That became the daily ritual: choose your mood, reveal your daily card, read a reflection prompt, and optionally write a few words. The aim is to make a small check-in easy, even when you don’t have a major question to ask.

For people who want to go further, I added six guided themes covering space, boundaries, change, confidence, connection, and direction. Each has five short chapters: notice the situation, consider another perspective, choose a small action, identify obstacles, and find support.

These explorations use curated branches rather than generating every step with AI. Earlier choices influence later options. Personal notes are optional and don’t automatically trigger a model call.

This gives me content I can review and improve consistently. Open-ended AI readings still have a place, but they don’t need to power every interaction.

Completed rituals, explorations, and explicitly saved readings go into a personal Journey timeline. The intention is to give people something worth revisiting: their own thoughts and choices, not just a list of cards.

I also added an opt-in weekly companion board. It shows names, avatars, and activity points, but not private reflections. Points are separate from purchases and don’t depend on someone’s mood or how much they write.

There’s a tension here: even a gentle leaderboard can create comparison. Whether it feels supportive is something I need users to tell me. These are product hypotheses, not proven retention improvements.

A small stack, with more state than I expected

The stack is Nuxt 3 for the statically generated frontend, a separate Fastify API, SQLite, and DeepSeek for generated readings. Nginx routes API requests to the backend.

For the current scale, I want something I can deploy and troubleshoot on my own. The difficult work has mostly been in the behavior of the application, not the number of services.

A daily card becomes account data once it connects to reflections, history, and rewards. Someone opening the site on their phone should see the same record they started on their laptop. Completion and rewards need consistent server-side state.

Disabling a button helps the interface, but it doesn’t prevent retries or requests from another tab.

Guided exploration saves have a similar problem. If a laptop has already saved the next chapter while a phone still has an older revision, accepting the phone’s write could overwrite newer progress.

Relevant save requests carry a revision. A stale write gets a conflict response, and the frontend keeps the draft while offering to reload saved progress. Identical committed retries return the existing result.

These are easy details to overlook when you only test one browser tab on a reliable connection.

The content needed versioning, too

One of the more interesting problems came from changing the exploration itself.

Suppose a saved answer says the user selected option 1. If I reorder the options next week, that stored value can appear to mean something different.

This is a simplified example of the problem:

Version 1, option 1: Take time to reflect privately
Version 2, option 1: Talk to someone you trust

The number didn’t change. The user’s apparent answer did.

An exploration therefore retains the content version it started with. Old option meanings need to remain stable, and the live chapter and saved recap need to interpret answers through the same branch logic.

Once copy gives meaning to stored answers, editing it is also a data-compatibility decision.

Weekly reflections brought another state problem. A generation request can time out, a retry can start, and the original request can finish late. Without a guard, that older result could overwrite the newer one.

The implementation uses a generation state, an expiring lease, and a version condition when writing the result. A short database transaction protects state changes; it doesn’t stay open while waiting for the model.

A paid AI request has more than two outcomes

The demo treated generation as success or failure. Streaming makes that less tidy: a request can return some text, stall, lose its client connection, or finish without usable content.

Deep readings use server-sent events. The server applies a timeout and attempts to cancel the upstream request if the client disconnects early. Only a complete successful result goes into the result cache.

If generation fails after credits have been deducted, the error path restores those in-app credits and provides a local card interpretation. Restoring credits is separate from refunding a payment through the payment provider.

Weekly reflections also have a model-call budget and a local fallback. A free feature still needs a cost boundary.

This isn’t a complete recovery system. For example, a process crash after a deduction cannot be recovered by a catch block in that same process. Durable job state and reconciliation remain areas to improve.

That distinction matters: having an error handler is not the same as having verified recovery from every failure.

Security extends beyond the prompt

The model generates text. It doesn’t decide account permissions, payment status, or credit balances, and it has no database or payment tools.

That limits the consequences of a manipulated response, but it doesn’t solve prompt injection. User input can still interfere with the intended task, and model output needs to be treated as untrusted content when it reaches the UI.

The service currently has request rate limiting, body-size limits, and account and credit checks before paid generation. These are basic controls, not a claim of comprehensive protection. IP-based limits have limitations, and input handling and output rendering require their own review.

For accounts, passwords use salted hashes, the database stores hashes of session tokens, and session cookies use HttpOnly and SameSite settings, with Secure enabled for production. Verification codes expire and have attempt limits.

Payments have a separate trust boundary. The backend confirms payment status with the provider and verifies webhook signatures. Order-status requests check ownership. Since polling and a webhook can both confirm the same payment, crediting an order must be idempotent.

Privacy also affects ordinary feature decisions. The feedback form doesn’t automatically attach someone’s journal entries. Analytics can record that a reflection was saved without collecting its text.

I still have security work to do. Keeping track of what each component can access—and where personal content goes—has been more useful than treating safety as a few lines in a system prompt.

Performance and localization added their own work

Static generation lets me serve public pages separately from account APIs, but it doesn’t automatically make the experience fast. Images, animations, authentication checks, and API latency still matter on a phone.

The Journey timeline is paginated, details load on demand, and uploaded avatars are cropped and compressed to WebP in the browser. Streaming also needs the proxy to cooperate: response buffering can hide the incremental output the server is sending.

The interface supports eight languages, while the card data is primarily English and Chinese, with English fallback elsewhere. Those are different levels of localization, and I shouldn’t present them as equivalent.

A recent bug was a good reminder of the extra surface area: an email placeholder contained a literal @, which the i18n message compiler interpreted as special syntax. The JSON was valid, but the page failed. A JSON parse check alone couldn’t catch it.

Even a small copy change needs the right kind of validation.

Shipping didn’t bring users automatically

I’ve shared the product on Solo, 出海栈, 小众软件, and Indie Hackers. That has given it places to be discovered, but I don’t yet have enough evidence to call any channel a repeatable source of users.

I’m also learning to separate people who enjoy a development story from people who want the product. Developers may find concurrency handling interesting. A potential user wants to know what they can do, how much effort it takes, and whether their writing stays private.

There’s overlap, but a well-read technical post doesn’t prove demand.

My next experiments are technical retrospectives like this one, short product demonstrations, and content built around concrete reflection scenarios. Search is another ongoing task: a readable sitemap and a renderable page are necessary pieces, but I still need public content that answers something people actually look for.

What I want to measure is the path after a visit: does someone complete a first ritual, continue to another exploration chapter, or return a few days later? Knowing where that stops should help me choose between improving the entry flow, the content, or the acquisition channel.

Writing more code is the comfortable option. It gives me a visible result. Asking someone to try the product can end with “I’ll take a look” and nothing else. I’m trying not to mistake the comfort of development for evidence that another feature is needed.

Where the project is now

Mystic Journey is still early. I’m looking for a small group of people willing to try it and tell me what feels useful, confusing, or unnecessary.

The daily ritual and guided explorations are free; deeper AI readings use credits. If tarot is unfamiliar, you can start with an exploration theme that fits something you’re thinking about.

Try Mystic Journey

Specific feedback would help most: where you got stuck, what didn’t make sense, or where you stopped wanting to continue. There’s a feedback form in the app, and comments here are welcome too.

If you’ve taken a side project beyond the demo stage, I’d also like to hear how you found your first users who came back.

I Built TGDown, a Chrome Extension for Downloading Telegram Web Media

On Pounch Man — Thu, 17 Sep 2026 03:17:08 +0000

I built TGDown, a Chrome extension that adds download controls for images and videos in Telegram Web.

The original product goal was simple: when users browse a Telegram chat, channel, or search result, they should be able to save media without repeatedly opening the viewer, fighting the context menu, or handling every item one by one.

The implementation was less simple.

Telegram Web is a large, fast-moving single-page application. An extension needs to add UI without breaking scrolling, media interactions, theme behavior, or Telegram's own event handling. This post is about the architecture behind TGDown — and a dark-mode bug that forced me to rethink how its in-page UI was mounted.

What TGDown does

TGDown supports both Telegram Web interfaces:

web.telegram.org/a/*
web.telegram.org/k/*

It provides:

One-click image and video downloads inside chats
Batch downloads from Telegram search results
A popup panel that lists detected media
Warnings for very large or long videos before a browser download starts
No separate TGDown account or subscription

The extension architecture

TGDown is a Manifest V3 extension built with TypeScript and Vue.

There are three execution contexts involved:

Content script

Runs alongside Telegram Web, watches the DOM for supported images and videos, and mounts download controls.
Page-context script

Some downloads need Telegram Web's existing authenticated browser session. Since a content script is isolated from the page's JavaScript context, TGDown injects a small page-context script and communicates with it through DOM events.
Extension pages

The toolbar popup is a Vue application. It lists media detected while browsing and can trigger a download from the active Telegram tab.

This separation keeps Telegram Web responsible for its own session, while the extension stays isolated from the application's internal code as much as possible.

The dark-mode white-screen bug

One of the most interesting bugs appeared only in Telegram's dark theme.

My first approach for modal-style UI used a full-screen iframe. The iframe had a transparent background, which seemed like a safe way to isolate extension styles from Telegram's styles.

In practice, it was not safe.

On a dark Telegram page, users would occasionally see the entire page turn white. It looked as if Telegram had failed to load, but the problem was the extension UI.

The sequence was roughly:

A full-screen iframe was inserted above Telegram.
The browser created the iframe document.
Before the iframe application had initialized — or when initialization failed — the iframe document rendered the browser's default page canvas.
That canvas was white, even though the iframe element itself was configured as transparent.
Because the iframe covered the viewport, it hid Telegram completely.

The bug was much easier to notice in dark mode because a white flash or white overlay has maximum contrast against Telegram's dark UI. In light mode, the same failure could be almost invisible.

The key lesson was simple:

A transparent iframe element does not guarantee a transparent iframe document.

The fix: Shadow DOM instead of a full-screen iframe

I removed the full-screen iframe from the Telegram page UI path.

TGDown now mounts its in-page controls in a Shadow DOM host. This preserves CSS isolation while avoiding a separate document with its own default rendering surface.

The host is also designed not to interfere with Telegram:

.tgdown-host {
  pointer-events: none;
}

.tgdown-host .download-button,
.tgdown-host .modal,
.tgdown-host .toast {
  pointer-events: auto;
}

The host itself ignores pointer events. Only actual TGDown controls opt back in, so Telegram remains clickable and scrollable everywhere else.

Keeping the integration conservative

Telegram Web has its own click handling, overlays, media viewer, and virtualized message list. A browser extension can easily become too aggressive: global CSS overrides, broad event listeners, or page-wide z-index layers may fix one download issue while breaking unrelated Telegram behavior.

TGDown takes a narrower approach:

It only targets supported media elements and its own controls.
It avoids replacing Telegram's global objects or fetch implementation.
It waits until Telegram has completed its initial page load before injecting behavior that depends on the page context.
It uses Shadow DOM rather than global CSS to isolate extension UI.
It keeps the UI non-interactive by default, enabling pointer events only for visible TGDown controls.

Telegram Web can still change its DOM structure, but keeping the integration narrow makes failures more contained and easier to diagnose.

Browser downloads still have limits

For regular images and videos, browser downloads work well. Larger media is different: browser memory, network stability, and the way Telegram Web exposes media URLs can affect reliability.

TGDown warns before especially large or long downloads, but leaves the final decision to the user.

Try TGDown

If Telegram Web changes and TGDown stops detecting a specific kind of media, feedback is welcome. The most helpful report includes the Telegram Web version (A or K), media type, and reproducible steps.

I Built TabScribe: A Free Chrome Extension to Copy All Browser Tabs as Markdown (Under 100KB, 12 Languages)

On Pounch Man — Sun, 07 Jun 2026 11:47:17 +0000

Why I Built TabScribe

After yet another research session where I found myself manually copying 20+ browser tab URLs one by one into my Obsidian notes, I decided enough was enough. I needed a tool that could copy all my tabs at once — in Markdown format.

I searched the Chrome Web Store. The existing options were either:

Too bloated (OneTab at 2M+ users, but does way more than I need)
Only supported plain text URL lists (Copy All URLs)
Abandoned for years (the old TabCopy extension)

So I built TabScribe over a couple of weekends.

What TabScribe Does

One click → all your tabs land in your clipboard in your chosen format:

Markdown [title](url) — perfect for Obsidian, Notion, VS Code
JSON array — great for data processing
Plain text — with custom delimiters
HTML unordered list — for web-based notes

Key Features

⚡ Keyboard Shortcut (Alt+Shift+C) — Copy all tabs without opening the popup

💾 Save & Restore Tab Groups — Save your tabs as named groups locally. Restore them in a new window later. Great for context switching.

📤 Export as Files — .md, .txt, .json, or .html with auto timestamps

🎯 Smart Filtering — Auto-excludes chrome://, edge://, about: pages. Optionally exclude pinned tabs.

🔧 Custom Delimiter — Set your own separator for text output (e.g., | for CSV-style)

🌐 12 Languages — English, 中文, 日本語, 한국어, Deutsch, Français, Español, Português, Русский, Bahasa Indonesia, and more

🎨 Dark Mode — Auto-follows system theme

Technical Deep Dive

Tech Stack

Preact + TypeScript + Tailwind CSS + Vite + crxjs
Bundle: ~63KB (gzipped: ~17KB)
Dependencies: 0 external runtime deps

I chose Preact over React deliberately. For a Chrome extension popup, every kilobyte matters. Preact's 3KB footprint vs React's 40KB+ is a no-brainer. Plus, with @preact/preset-vite, the DX is nearly identical.

The Clipboard Challenge (Manifest V3)

The hardest technical problem was clipboard access in Manifest V3's Service Worker context.

In MV3, the background page is replaced by a Service Worker — which has no DOM. The document.execCommand('copy') fallback doesn't work there. Here's my solution:

// Double-fallback clipboard strategy
async function copyToClipboard(text: string, html?: string) {
  // Strategy 1: Modern Clipboard API (works in popup + offscreen)
  try {
    const item = new ClipboardItem({
      'text/plain': new Blob([text], { type: 'text/plain' }),
      ...(html ? { 'text/html': new Blob([html], { type: 'text/html' }) } : {}),
    });
    await navigator.clipboard.write([item]);
    return;
  } catch { /* fall through */ }

  // Strategy 2: execCommand fallback (popup context only)
  if (typeof document !== 'undefined') {
    const textarea = document.createElement('textarea');
    textarea.value = text;
    document.body.appendChild(textarea);
    textarea.select();
    document.execCommand('copy');
    document.body.removeChild(textarea);
    return;
  }

  // Strategy 3: Chrome Offscreen Document (Service Worker context)
  await chrome.offscreen.createDocument({ /* ... */ });
  // Route clipboard write through the offscreen document
}

i18n Architecture

I used Chrome's built-in chrome.i18n API with 12 locale JSON files. The extension name and description in manifest.json use __MSG_key__ placeholders, so the Chrome Web Store automatically displays the right language.

// _locales/ja/messages.json
{
  "extensionName": { "message": "TabScribe" },
  "extensionDesc": { "message": "すべてのタブをMarkdown/JSON/HTMLで一括コピー" }
}

Privacy by Design

TabScribe collects zero data. Period.

No analytics
No tracking pixels
No external servers
No network requests (except extension updates from Chrome)
Everything stored in chrome.storage.local

Only 6 permissions requested, each with a clear purpose:

Permission	Why
`tabs`	Read tab titles & URLs
`clipboardWrite`	Copy formatted text
`storage`	Save preferences & tab groups locally
`commands`	Register keyboard shortcut
`downloads`	Save exported files
`offscreen`	Clipboard access in Service Worker

Try It

🔗 TabScribe on Chrome Web Store

It's free. No signup. No tracking. Just productivity.

Built with Preact + TypeScript + Tailwind CSS. Source code available on GitHub.