DEV Community: Latr

How we share 50 browser tabs with a single URL and zero backend servers

Latr — Tue, 13 Oct 2026 11:25:00 +0000

Using the URL hash fragment to compress and share entire browser sessions, windows, and tab groups without a database, backend, or user accounts.

When building Latr, our browser extension for tab management and tab reminders, we wanted a simple way for people to share a collection of tabs.

Think about common scenarios:

Sending a colleague five reference pull requests and design docs for a sprint task.
Sharing a curated pack of research papers or tutorials with a student.
Moving a window of twelve open tabs from a work laptop to a personal machine.

The industry-standard way to build this is predictable:

Spin up an API endpoint (POST /api/sessions).
Store the URLs in PostgreSQL or Redis.
Generate a short ID (https://service.com/s/xyz123).
Require user authentication to manage or delete the links.

We did not do any of that. Latr runs with zero backend servers, zero databases, and zero user accounts.

Instead, we pack the entire collection of tabs directly into the URL fragment. Here is how that architecture works, how we keep URLs compact, and the security checks needed when decoding arbitrary data on the client.

The Foundation: RFC 3986 and the Hash Fragment

The whole trick relies on a fundamental rule of browser networking:

https://latr.page/add#eyJ0IjoiRG9jcyIsInUiOiJodHRwczovL2V4YW1wbGUuY29tIn0
└─────── static host ─┘└──────── client-only payload ─────────────────┘

Everything after the # (the fragment identifier) is strictly client-side. Web browsers never transmit the fragment in HTTP request headers.

That single property gives us three major advantages:

Zero server infrastructure: The landing page is just a static HTML file hosted on Cloudflare Pages. It costs nothing to serve.
True privacy: Neither our static host, nor Cloudflare edge logs, nor any middleman can see the URLs or page titles inside the link. The data only exists on the sender's device and the recipient's device.
Infinite lifetime: Because there is no database, records never expire, get purged, or fail during server migrations.

Packing 50 Tabs into a Link

URL lengths cannot grow indefinitely. While browsers can technically handle tens of thousands of characters, chat apps like Slack, Discord, and WhatsApp often truncate links that exceed 8KB.

To fit dozens of tabs into a sharable link, we use a compact JSON schema before base64url encoding.

1. Single tab schema

For a single shared page or reminder, we use single-character keys:

{
  "t": "Page Title",
  "u": "https://developer.mozilla.org/...",
  "w": 1728640000000
}

t: Title (clamped)
u: URL
w: Optional timestamp (when the tab reminder is due)

2. Multi-tab session schema

For an entire window, tab group, or library selection:

{
  "n": "Design System PRs",
  "r": [
    { "t": "Tokens Spec", "u": "https://..." },
    { "t": "Button Component", "u": "https://..." }
  ]
}

n: Session or window name
r: Array of tab records

We deliberately strip out internal state. Local tags, notes, scroll anchors, and personal IDs are omitted. The recipient gets the clean pages, nothing personal.

Here is the encoder in TypeScript / JavaScript:

export function toSessionLink(name, tabs) {
  // Cap at 50 tabs to stay comfortably under URL limits
  const members = tabs.slice(0, 50).map((tab) => ({
    t: (tab.title || '').slice(0, 150),
    u: tab.url,
  }));

  const payload = { n: name.slice(0, 80), r: members };
  const json = JSON.stringify(payload);
  const encoded = toBase64Url(json);

  return `https://latr.page/add#${encoded}`;
}

function toBase64Url(str) {
  const bytes = new TextEncoder().encode(str);
  let binary = '';
  for (let i = 0; i < bytes.byteLength; i++) {
    binary += String.fromCharCode(bytes[i]);
  }
  return btoa(binary)
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '');
}

At typical title lengths, 10 tabs compress to roughly 1.2KB. A full pack of 50 tabs lands around 6KB to 7.5KB, well within chat link handling limits.

The Security Boundary: Decoding Untrusted Fragments

Because any stranger can construct a link and send it to someone, treating location.hash as trusted data would be dangerous.

When the recipient lands on the static /add page, the decoder runs a strict validation pipeline before rendering:

export function fromShareLink(hashString) {
  try {
    const raw = hashString.replace(/^#/, '');
    if (!raw) return null;

    const json = fromBase64Url(raw);
    const data = JSON.parse(json);

    // Verify session payload shape
    if (data && Array.isArray(data.r)) {
      const validTabs = [];
      for (const item of data.r) {
        if (isValidTab(item)) {
          validTabs.push({
            title: String(item.t).slice(0, 150),
            url: item.u,
          });
        }
      }
      if (validTabs.length === 0) return null;
      return { name: String(data.n || 'Shared Tabs').slice(0, 80), tabs: validTabs };
    }

    // Single tab fallback
    if (isValidTab(data)) {
      return {
        name: String(data.t || 'Shared Tab').slice(0, 80),
        tabs: [{ title: String(data.t).slice(0, 150), url: data.u }],
      };
    }

    return null;
  } catch {
    return null;
  }
}

function isValidTab(item) {
  if (!item || typeof item.u !== 'string') return false;

  // CRITICAL: Protocol whitelist
  // Reject javascript:, file:, data:, or chrome: links
  try {
    const parsed = new URL(item.u);
    return parsed.protocol === 'http:' || parsed.protocol === 'https:';
  } catch {
    return false;
  }
}

Key security practices here:

Protocol enforcement: Only http: and https: URLs are accepted. This stops dangerous payload injection like javascript: or local file:/// URIs from ever reaching browser navigation calls.
Per-item failure tolerance: If one tab in a list of twenty is malformed, we drop that single tab rather than crashing the whole import. The recipient still gets the other nineteen valid pages.
Input clamping: String lengths for titles and names are truncated immediately to prevent DOM rendering issues.

What the Recipient Sees

When someone opens the link:

If they have the extension installed, a background handshake offers to open all tabs immediately, save them as a clean tab group, or store them in their library.
If they do not have the extension installed, the static web page displays an interactive, clickable checklist of all shared links. They can open individual links or copy them in one click.

Tradeoffs of the Serverless Approach

This pattern is not suitable for every application. Here are the honest tradeoffs:

No revocation: You cannot "delete" a link once you send it. If you paste it into a public Slack channel, anyone with the link can view the payload indefinitely.
No analytics on clicks: Because the fragment never touches a server, the sender cannot track who clicked or how many times it was opened.
Payload ceilings: You cannot pack 500 tabs into a single URL without breaking browser URI length limits.

For sharing everyday collections of 5 to 50 tabs, however, these tradeoffs are actually features. Users get instant sharing with no logins, zero tracking, and absolute data privacy.

If you want to test how the decoding feels or explore local-first tab organization, check out Latr. The entire extension is designed around zero install-time permission warnings and local storage.

Why Chrome tabs eat memory, and how we built real-time duplicate prevention in Manifest V3

Latr — Mon, 12 Oct 2026 11:23:00 +0000

Handling duplicate tabs, URL normalization, automated grouping rules, and memory management in a local-first Chrome extension.

If you keep your browser open across a working day, you almost certainly accumulate duplicate tabs.

You open a pull request in the morning. At 2 PM someone pings a link to that same PR in Slack, and you click it. At 4 PM you click an email notification about a review comment on that same PR. Now you have three identical tabs loaded into RAM, spread across different windows.

Chrome and Edge provide a native tab search shortcut (Ctrl+Shift+A), but no built-in way to automatically detect, deduplicate, or prevent duplicate tabs.

When we built Latr, our local-first browser workstation, duplicate handling became one of our core features.

It sounds deceptively simple on paper: just match URLs and close the second one. In practice, building automated duplicate detection and tab management in a production browser extension brings up several tricky engineering problems.

Here is what we learned building it under Manifest V3.

The Normalization Problem: When Are Two URLs Actually the Same?

A naive duplicate check uses strict string equality (tabA.url === tabB.url). In the real world, that fails more often than it succeeds.

Consider these four URLs:

https://github.com/facebook/react/pull/1234
https://github.com/facebook/react/pull/1234/ (trailing slash)
https://github.com/facebook/react/pull/1234?utm_source=slack&utm_medium=chat (marketing parameters)
https://github.com/facebook/react/pull/1234#issuecomment-5678 (comment anchor)

If a link arrives from Slack, Twitter, or an email, it carries tracking parameters like utm_source, utm_campaign, fbclid, or gclid. The user is looking at the exact same document, but the URL strings differ.

Here is how we normalize URLs before running the duplicate detection:

const TRACKING_PARAMS = new Set([
  'utm_source',
  'utm_medium',
  'utm_campaign',
  'utm_term',
  'utm_content',
  'fbclid',
  'gclid',
  'ref',
  'source',
]);

export function normalizeUrl(rawUrl, { ignoreHash = false } = {}) {
  try {
    const parsed = new URL(rawUrl);

    // Normalize protocol and hostname
    parsed.protocol = parsed.protocol.toLowerCase();
    parsed.hostname = parsed.hostname.toLowerCase();

    // Drop trailing slash on path
    if (parsed.pathname.length > 1 && parsed.pathname.endsWith('/')) {
      parsed.pathname = parsed.pathname.slice(0, -1);
    }

    // Strip known tracking parameters
    for (const key of Array.from(parsed.searchParams.keys())) {
      if (TRACKING_PARAMS.has(key.toLowerCase())) {
        parsed.searchParams.delete(key);
      }
    }

    // Sort remaining query params so order does not matter
    parsed.searchParams.sort();

    // Optionally ignore fragment identifier
    if (ignoreHash) {
      parsed.hash = '';
    }

    return parsed.toString();
  } catch {
    return rawUrl;
  }
}

By stripping known tracking tokens and sorting the remaining query parameters, links clicked from notifications match tabs that were opened manually.

Guard Rails: What You Must Never Automatically Close

Closing a duplicate cannot be an aggressive, indiscriminate script. In browser extension development, destroying a user's uncommitted work is the worst bug you can ship.

Before flagging or closing any tab as a duplicate, our duplicate filter enforces four safety rules:

Never close pinned tabs: A pinned tab is an explicit declaration of intent. It stays.
Never close audible tabs: If a duplicate tab is currently playing audio (such as a meeting, podcast, or YouTube video), touching it is jarring and unexpected.
Never close active tabs: If the user is currently looking at a tab, that tab is exempt. The older background copy is the candidate for closing, never the active viewport.
Never touch system or local pages: Internal URLs (chrome://, about:, file://, extension setup pages) are excluded outright.

Here is how that filtering looks in practice:

export function duplicateTabs(tabs = [], { loose = false } = {}) {
  const seen = new Map();
  const duplicates = [];

  for (const tab of tabs) {
    // Safety checks
    if (!tab.url || !/^https?:/i.test(tab.url)) continue;
    if (tab.pinned) continue;
    if (tab.audible) continue;

    const key = normalizeUrl(tab.url, { ignoreHash: loose });

    if (seen.has(key)) {
      // The earlier tab survives; this later copy is marked as duplicate
      duplicates.push(tab);
    } else {
      seen.set(key, tab);
    }
  }

  return duplicates;
}

Real-Time Prevention: The onCreated vs onUpdated Race Condition

Finding duplicates on demand inside an extension popup is straightforward. Doing it in real time as links open requires handling browser lifecycle timing.

When an external program (like Slack or an IDE) opens a URL:

chrome.tabs.onCreated fires, but tab.url is often empty or about:blank while the initial process allocates.
chrome.tabs.onUpdated fires multiple times as the page navigates (status: 'loading'), receives headers, and completes (status: 'complete').

If duplicate prevention is turned on, running the check on onCreated misses the incoming URL. Running it blindly on every onUpdated event causes redundant queries across every window.

The solution is to hook onUpdated, listen specifically for the first time changeInfo.url appears, verify if an existing tab in any open window shares the normalized URL, focus that existing tab, and silently close the new duplicate before it consumes full render memory.

chrome.tabs.onUpdated.addListener(async (tabId, changeInfo, tab) => {
  if (!changeInfo.url) return;
  if (!settings.preventDuplicates) return;

  const targetKey = normalizeUrl(changeInfo.url);
  const allTabs = await chrome.tabs.query({});

  const match = allTabs.find((existing) => 
    existing.id !== tabId && 
    !existing.pinned && 
    normalizeUrl(existing.url) === targetKey
  );

  if (match) {
    // Jump to the tab the user already had open
    await chrome.tabs.update(match.id, { active: true });
    await chrome.windows.update(match.windowId, { focused: true });

    // Close the redundant incoming tab
    await chrome.tabs.remove(tabId);
  }
});

The Memory Angle: Discarding Inactive Tabs

Closing duplicates helps, but what about the 30 tabs you actually want to keep open?

Modern browsers consume hundreds of megabytes per open tab because each tab maintains its own isolated process, DOM tree, and JavaScript runtime.

Instead of closing tabs, Manifest V3 extensions can leverage chrome.tabs.discard(tabId).

Calling discard() instructs the browser engine to dump the tab's renderer process and memory footprint while keeping the tab visible in the tab strip. The title, favicon, and URL remain completely intact. When the user eventually clicks back to that tab, the browser restores it from cache.

We combined this with our duplicate cleanup: users can see their total open tab count, close real duplicates in one click, and put idle tabs to sleep to immediately recover RAM without losing their layout.

Final Thoughts

Tab management tools often fail when they try to become complex workspaces that force users to adopt an entirely new system.

By focusing on small, high-leverage problems (stripping tracking parameters, intercepting redundant links, and discarding cold tabs), you can solve the tab clutter problem natively inside the browser.

If you want to try out duplicate prevention and tab snoozing in a lightweight, local-first utility, give Latr a look. It requires zero install-time permission warnings and keeps all data on your machine.

Why saving scroll position in a browser extension is broken (and how text fragments fix it)

Latr — Sun, 11 Oct 2026 10:12:18 +0000

When you build a tab snoozer or a "save for later" tool, you quickly realize something: a browser tab is not just a URL. It is an intention, and it is a reading position.

If someone is two-thirds through a 4,000-word documentation page or an RFC and gets pulled into a meeting, closing the tab feels risky. Reopening the tab tomorrow at the very top of the page forces them to hunt for where they left off.

Naturally, the first instinct as a developer is simple: just record window.scrollY when saving the page, and run window.scrollTo() when reopening it.

In practice, that approach turns out to be both unreliable and a permissions nightmare.

Here is why pixel-based scroll restoration breaks in production, and how we solved it using standard W3C text fragments instead.

The Two Traps of Pixel Scroll Offsets

1. Pixel offsets are fragile

A scroll offset is tied to a specific render pass:

If the user reopens the tab on an external monitor with a different viewport width, text wraps differently and the offset is wrong.
If the page uses lazy-loaded images or responsive embeds, layout shifts occur after load. By the time the images finish loading, the pixel position points to empty space.
If the site updates its stylesheet or layout in the days between saving and reopening, a pixel offset becomes completely meaningless.

2. The Manifest V3 permissions trap

To run window.scrollTo() when a tab reopens from a notification click or extension popup, the extension needs to execute a script inside that reopened tab.

Under Manifest V3, activeTab only grants temporary script execution when the user invokes an action directly on that active tab (such as clicking the extension icon or pressing an extension shortcut on that page).

A background notification click opening a tab via chrome.tabs.create() does not qualify as a user gesture on that new tab. To inject a script there, the extension would have to request <all_urls>:

"Read and change all your data on all websites"

Demanding that permission on the install dialog destroys user trust immediately, especially for a tool that promises to be local-first and privacy-focused.

The Solution: Native Text Directives

Instead of storing coordinates, the browser can anchor to the actual content using W3C Scroll-to-Text Fragments:

https://example.com/article#:~:text=the%20sentence%20you%20were%20reading

When Chromium opens that link, the rendering engine finds the specified text, scrolls to it, and highlights it.

This completely changes the permission model:

Zero code injected at reopening: The browser itself handles the scroll during regular navigation.
Zero host permissions required: The extension never touches the reopened page.
Layout-agnostic: It does not matter if images take three seconds to load or if the viewport width changed. The browser anchors directly to the text node.

How We Implemented Capture with activeTab

While reopening requires no permissions, capturing the visible line at save time does require reading the page. Because saving happens via user action (clicking the toolbar icon or pressing Alt+Shift+Y), activeTab applies cleanly.

Here is a simplified version of the node detection logic from our codebase:

function getVisibleReadingAnchor() {
  // Ignore saves near the top of the page
  if (window.scrollY < 100) return null;

  const viewportHeight = window.innerHeight;
  // Scan elements starting around 15% from the top
  const targetY = viewportHeight * 0.15;
  const targetX = window.innerWidth / 2;

  let el = document.elementFromPoint(targetX, targetY);
  if (!el) return null;

  // Skip headers, navigation, footers, and sticky elements
  while (el && el !== document.body) {
    const tag = el.tagName.toLowerCase();
    const style = window.getComputedStyle(el);
    if (['nav', 'header', 'footer', 'aside'].includes(tag) || 
        style.position === 'fixed' || 
        style.position === 'sticky') {
      return null;
    }
    el = el.parentElement;
  }

  // Extract clean text from the target node
  const text = el?.innerText?.trim();
  if (!text || text.length < 25) return null;

  // Build the text directive query
  const cleanSnippet = encodeURIComponent(text.slice(0, 120));
  return `#:~:text=${cleanSnippet}`;
}

Edge Cases Discovered in the Wild

Building this across real websites revealed several interesting quirks:

Document order is not reading order: On Wikipedia, the table of contents often appears early in the DOM and sits fixed on screen. Early prototypes anchored almost every Wikipedia article to the word "Contents". Skipping <nav> and sticky containers is essential.
Short labels versus real reading sentences: A page with lots of short metadata (like an issue tracker or release notes) does not have long paragraphs. Setting a strict paragraph length requirement fails on technical docs. We ended up preferring sentences longer than 25 characters, but falling back to shorter phrases if nothing else existed.
Graceful degradation: If an article is edited or removed between saving and reopening, the browser silently ignores the #:~:text= fragment and loads the standard URL from the top. The user is never worse off for having tried.

Takeaway

Before reaching for broad extension permissions or trying to simulate viewport state with JavaScript coordinates, look at what browser standards already provide. Native text fragments let us deliver exact reading position restoration while keeping our extension completely free of install-time permission warnings.

If you are interested in local-first browser utilities or want to see how this feels in practice, we built this into Latr, an open project focusing on tab reminders, tab grouping, and duplicate cleanup without user accounts or tracking servers.

Have you experimented with text fragments or URL directives in your own projects? Would love to hear your thoughts in the comments.