How I Turned a Cluttered Browser Workflow Into a Chrome Extension With 83 Tools

As I started documenting the products I have built over time, I decided to begin with one of the earliest: Toolboard.

Browser workflows rarely become frustrating because one important feature is missing. They become frustrating because useful actions are scattered across separate extensions, websites, menus, and tabs.

I had one extension for screenshots, another for colors, another for fonts, separate websites for data conversion, and a growing set of small utilities I repeatedly searched for. Each tool solved a real problem. Together, they created a fragmented workflow.

So I built one place for them.

Toolboard is a Manifest V3 Chrome extension that brings 83 browser tools into a single searchable interface. It covers inspection, capture, browsing enhancements, general utilities, format conversion, structured-data previewing, and AI-assisted workflows.

This post is less about listing 83 features and more about the product and engineering decisions required to stop 83 features from becoming a mess.

The product boundary

The initial idea was simple:

Put the small browser tools I use regularly behind one consistent interface.

That boundary mattered. Toolboard was not meant to become a second browser or a giant automation platform. It was meant to reduce the friction between noticing a task and completing it.

Examples include:

• inspecting a color, font, element, or link on the current page;
• capturing a screenshot, page text, media, PDF, QR code, or tab recording;
• adding sticky notes, highlights, reading mode, bookmarks, or dark mode;
• converting units, currencies, time zones, colors, timestamps, encodings, data formats, images, and subtitles;
• previewing JSON, CSV/TSV, Markdown, XML, PDFs, images, OpenGraph metadata, schema data, and links;
• summarizing, translating, analyzing, or discussing page content with AI.

As the project grew, the tools settled into seven categories:

Category	Examples
Inspect	Color Picker, Element Picker, Font Finder, Link Picker
Capture	Screenshot Picker, Media Download, Text Picker, PDF Generator, QR Generator, Video Recorder
Enhance	Sticky Notes, Reading Mode, Text Highlighter, Bookmark Manager, Dark Mode
Utilities	Site Info, Color Palette Generator, Copy History, Macro Recorder
Converters	Units, currency, time zones, Base64, URLs, UUIDs, hashes, JWTs, JSON/YAML, CSV/JSON, XML/JSON, images, media, subtitles, and more
Previewers	JSON, CSV/TSV, Markdown, XML, PDF, image, OpenGraph, schema, and link previews
AI	Summarizer, Translator, Content Detector, Email Generator, SEO Analyzer, AI Chat

The breadth is useful, but breadth immediately creates a second problem: discoverability.

Adding tools was not the hard part

The difficult part was not writing another converter or picker. The difficult part was keeping dozens of tools understandable, searchable, testable, and consistent.

Toolboard uses a central tool manifest as its product registry. Every tool declares information such as:

{
  "id": "color-picker",
  "name": "Color Picker",
  "category": "inspect",
  "module": "inspect/colorPicker.js",
  "icon": "color",
  "tags": ["color", "design", "palette"],
  "keywords": ["hex", "rgb", "hsl", "eyedropper"],
  "permissions": ["activeTab"]
}

This manifest became the source of truth for the interface and release process.

It lets the extension:

• build categories without hard-coding every card;
• search by names, tags, and related keywords;
• keep ordering predictable;
• connect tools to icons and localization keys;
• associate functionality with the permissions it needs;
• detect missing modules or inconsistent registrations before release.

That structure was more important than any individual feature. Without it, every new tool would have increased the amount of manual UI code and made future changes more fragile.

Designing for 83 choices

A grid containing 83 equally weighted options is not a productivity interface. It is a directory.

I added several layers to reduce that cognitive load:

Search

Users can search by tool name as well as related terms. Someone looking for “hex,” “eyedropper,” or “palette” should still reach the Color Picker.

Categories

The seven categories create a first-level mental model. A user does not need to remember the exact name of a tool if they know whether they want to inspect, capture, convert, or preview something.

Favorites and usage-based ordering

Frequently used tools can be marked as favorites. Favorites rise to the top, and usage frequency helps order tools within that group.

The goal is for Toolboard to become smaller for each user over time. The extension may contain 83 tools, but a person should mostly see the subset relevant to their own workflow.

Hidden tools

Not every feature is useful to every person. Tools can be hidden instead of forcing everyone to navigate the full catalog forever.

Consistent interaction patterns

Dozens of tools should not feel like dozens of unrelated mini-apps. Buttons, panels, previews, loading states, copy actions, downloads, and completion feedback need to behave consistently.

I even added small multilingual coffee-themed messages after successful operations. It is a minor detail, but consistency in small feedback moments helps a broad utility suite feel like one product rather than a folder of scripts.

The permission model is part of the product

A multi-tool browser extension naturally needs a wider permission surface than a single-purpose extension.

Toolboard uses permissions such as:

• activeTab and scripting for page inspection and tool activation;
• storage for preferences, favorites, notes, bookmarks, highlights, and local history;
• clipboardRead and clipboardWrite for copy-related workflows;
• downloads for generated or captured files;
• tabCapture for the video recorder;
• tabs where tab metadata is needed.

The extension also needs to operate across normal HTTP and HTTPS pages so the tools are available where the user needs them.

This makes transparency essential. A permission list should not be treated as a technical footnote. Users should be able to understand which capability needs each permission and what happens to their data.

Most Toolboard state stays in chrome.storage.local, including:

• favorites and hidden tools;
• per-site sticky notes and highlights;
• bookmarks and copy history;
• theme and onboarding preferences;
• tool usage data used for sorting.

There is no analytics or crash telemetry built into the extension.

AI features are different because they need a model endpoint. They use the user's own Gemini API key, and the relevant selected text or page content is sent to Gemini only when the user invokes an AI tool. API keys are encrypted locally before storage. A small number of converter features also use task-specific external services, such as exchange-rate or label-rendering APIs.

The lesson for me was simple: privacy is not a badge added to a README. It is a product surface that needs explicit controls, explanations, and boundaries.

AI as a tool category, not the entire product

Toolboard includes an AI Summarizer, Translator, Content Detector, Email Generator, SEO Analyzer, and a page-aware chat interface.

But I did not want every utility to become a chat prompt.

A color picker should still pick colors. A JWT decoder should still decode a token. A CSV previewer should still show a table immediately.

AI is useful where interpretation is required:

• condensing a long page;
• translating selected or full-page text;
• generating a structured email;
• reviewing SEO signals;
• discussing the current page with context.

It is less useful when a deterministic local operation can provide an immediate and reliable result.

Keeping AI as one category among seven helped preserve that distinction.

Release gates for a large extension

Feature count creates maintenance risk. A small change to the registry, icons, translations, or activation path can break tools that appear unrelated.

The release process therefore checks more than whether the JavaScript parses.

Automated tests validate areas such as:

• tool IDs being unique and consistently formatted;
• registered modules existing and exporting the expected shape;
• localization keys being present across English, Turkish, and French;
• every tool having a registered icon;
• the manifest and displayed tool count staying aligned;
• shared completion-message coverage remaining complete.

There is also a manual release checklist for preview rendering, repeated tool execution, fullscreen behavior, overlay closing, light/dark contrast, localization, and permission consistency.

This is one of the biggest lessons I took from Toolboard:

Shipping many small features does not reduce the need for engineering discipline. It multiplies it.

What I learned

1. Feature breadth changes the core problem

At first, the problem was building useful tools. Later, the problem became helping people find and trust the right tool quickly.

2. A registry-driven architecture scales better than manual UI wiring

The manifest gave the project a stable vocabulary for tools, categories, keywords, icons, localization, and permissions.

3. Consistency matters more as individual features become smaller

When each action is brief, inconsistent buttons, feedback, previews, or output handling become disproportionately noticeable.

4. Browser permissions require product communication

Technical justification is not enough. Permission use has to be understandable from the user's point of view.

5. AI should be applied selectively

AI added value to interpretation-heavy workflows, but many browser tasks remained better as fast, local, deterministic utilities.

Where the project stands

Toolboard is currently at version 3.0.1 and remains open source under the MIT License.

The repository includes the extension source, privacy documentation, tests, and release checklist:

ademisler / toolboard

A Chrome extension with 80+ productivity tools for inspection, capture, conversion, and AI-assisted workflows.

Toolboard

A comprehensive Chrome extension with 83 web productivity tools, including AI-powered features, a smart favorite system, converter suite, and coffee toast messages.

🚀 Features

AI-Powered Tools

• AI Summarizer - Intelligent text summarization with multiple length options
• AI Translator - Real-time translation with in-place page translation
• AI Content Detector - Detect AI-generated content with detailed analysis
• AI Email Generator - Professional email generation with customizable tone and type
• AI SEO Analyzer - Comprehensive SEO analysis with AI-powered scoring
• AI Chat - Intelligent conversational interface with persistent page context awareness

Inspection Tools

• Color Picker - Extract colors from any webpage element
• Element Picker - Inspect DOM elements and their properties
• Font Picker - Analyze fonts used on web pages
• Link Picker - Validate and analyze links

Capture Tools

• Screenshot Picker - Capture full page or selected area screenshots
• Text Picker - Extract text from web pages
• Media Picker - Extract images…

View on GitHub

I am especially interested in feedback on three areas:

1. Does the category structure match how you think about browser tools?
2. Which permissions or privacy boundaries need clearer explanations?
3. Should a broad tool such as this remain one extension, or should some categories eventually become focused standalone products?

This is the first article in a series documenting the products I have built—from browser utilities to newer AI-native developer tools and desktop systems.