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 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:
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.
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:
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.
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:
Users can search by tool name as well as related terms. Someone looking for “hex,” “eyedropper,” or “palette” should still reach the Color Picker.
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.
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.
Not every feature is useful to every person. Tools can be hidden instead of forcing everyone to navigate the full catalog forever.
Dozens of tools should not feel like dozens of unrelated mini-apps. Buttons, panels, previews, 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.
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:
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.
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:
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.
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:
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.
At first, the problem was building useful tools. Later, the problem became helping people find and trust the right tool quickly.
The manifest gave the project a stable vocabulary for tools, categories, keywords, icons, localization, and permissions.
When each action is brief, inconsistent buttons, feedback, previews, or output handling become disproportionately noticeable.
Technical justification is not enough. Permission use has to be understandable from the user's point of view.
AI added value to interpretation-heavy workflows, but many browser tasks remained better as fast, local, deterministic utilities.
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:
A comprehensive Chrome extension with 83 web productivity tools, including AI-powered features, a smart favorite system, converter suite, and coffee toast messages.
I am especially interested in feedback on three areas:
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.