{"slug": "how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools", "title": "How I Turned a Cluttered Browser Workflow Into a Chrome Extension With 83 Tools", "summary": "A developer has built Toolboard, a Manifest V3 Chrome extension that consolidates 83 browser tools into a single searchable interface. The project uses a central tool manifest as a product registry to manage discoverability and consistency across categories including inspection, capture, conversion, and AI-assisted workflows.", "body_md": "As I started documenting the products I have built over time, I decided to begin with one of the earliest: **Toolboard**.\n\nBrowser 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.\n\nI 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.\n\nSo I built one place for them.\n\n[Toolboard](https://github.com/ademisler/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.\n\nThis post is less about listing 83 features and more about the product and engineering decisions required to stop 83 features from becoming a mess.\n\nThe initial idea was simple:\n\nPut the small browser tools I use regularly behind one consistent interface.\n\nThat 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.\n\nExamples include:\n\nAs the project grew, the tools settled into seven categories:\n\n| Category | Examples |\n|---|---|\nInspect |\nColor Picker, Element Picker, Font Finder, Link Picker |\nCapture |\nScreenshot Picker, Media Download, Text Picker, PDF Generator, QR Generator, Video Recorder |\nEnhance |\nSticky Notes, Reading Mode, Text Highlighter, Bookmark Manager, Dark Mode |\nUtilities |\nSite Info, Color Palette Generator, Copy History, Macro Recorder |\nConverters |\nUnits, currency, time zones, Base64, URLs, UUIDs, hashes, JWTs, JSON/YAML, CSV/JSON, XML/JSON, images, media, subtitles, and more |\nPreviewers |\nJSON, CSV/TSV, Markdown, XML, PDF, image, OpenGraph, schema, and link previews |\nAI |\nSummarizer, Translator, Content Detector, Email Generator, SEO Analyzer, AI Chat |\n\nThe breadth is useful, but breadth immediately creates a second problem: **discoverability**.\n\nThe difficult part was not writing another converter or picker. The difficult part was keeping dozens of tools understandable, searchable, testable, and consistent.\n\nToolboard uses a central tool manifest as its product registry. Every tool declares information such as:\n\n```\n{\n  \"id\": \"color-picker\",\n  \"name\": \"Color Picker\",\n  \"category\": \"inspect\",\n  \"module\": \"inspect/colorPicker.js\",\n  \"icon\": \"color\",\n  \"tags\": [\"color\", \"design\", \"palette\"],\n  \"keywords\": [\"hex\", \"rgb\", \"hsl\", \"eyedropper\"],\n  \"permissions\": [\"activeTab\"]\n}\n```\n\nThis manifest became the source of truth for the interface and release process.\n\nIt lets the extension:\n\nThat 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.\n\nA grid containing 83 equally weighted options is not a productivity interface. It is a directory.\n\nI added several layers to reduce that cognitive load:\n\nUsers can search by tool name as well as related terms. Someone looking for “hex,” “eyedropper,” or “palette” should still reach the Color Picker.\n\nThe 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.\n\nFrequently used tools can be marked as favorites. Favorites rise to the top, and usage frequency helps order tools within that group.\n\nThe 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.\n\nNot every feature is useful to every person. Tools can be hidden instead of forcing everyone to navigate the full catalog forever.\n\nDozens 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.\n\nI 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.\n\nA multi-tool browser extension naturally needs a wider permission surface than a single-purpose extension.\n\nToolboard uses permissions such as:\n\n`activeTab`\n\nand `scripting`\n\nfor page inspection and tool activation;`storage`\n\nfor preferences, favorites, notes, bookmarks, highlights, and local history;`clipboardRead`\n\nand `clipboardWrite`\n\nfor copy-related workflows;`downloads`\n\nfor generated or captured files;`tabCapture`\n\nfor the video recorder;`tabs`\n\nwhere 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.\n\nThis 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.\n\nMost Toolboard state stays in `chrome.storage.local`\n\n, including:\n\nThere is no analytics or crash telemetry built into the extension.\n\nAI 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.\n\nThe 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.**\n\nToolboard includes an AI Summarizer, Translator, Content Detector, Email Generator, SEO Analyzer, and a page-aware chat interface.\n\nBut I did not want every utility to become a chat prompt.\n\nA color picker should still pick colors. A JWT decoder should still decode a token. A CSV previewer should still show a table immediately.\n\nAI is useful where interpretation is required:\n\nIt is less useful when a deterministic local operation can provide an immediate and reliable result.\n\nKeeping AI as one category among seven helped preserve that distinction.\n\nFeature count creates maintenance risk. A small change to the registry, icons, translations, or activation path can break tools that appear unrelated.\n\nThe release process therefore checks more than whether the JavaScript parses.\n\nAutomated tests validate areas such as:\n\nThere is also a manual release checklist for preview rendering, repeated tool execution, fullscreen behavior, overlay closing, light/dark contrast, localization, and permission consistency.\n\nThis is one of the biggest lessons I took from Toolboard:\n\nShipping many small features does not reduce the need for engineering discipline. It multiplies it.\n\nAt first, the problem was building useful tools. Later, the problem became helping people find and trust the right tool quickly.\n\nThe manifest gave the project a stable vocabulary for tools, categories, keywords, icons, localization, and permissions.\n\nWhen each action is brief, inconsistent buttons, feedback, previews, or output handling become disproportionately noticeable.\n\nTechnical justification is not enough. Permission use has to be understandable from the user's point of view.\n\nAI added value to interpretation-heavy workflows, but many browser tasks remained better as fast, local, deterministic utilities.\n\nToolboard is currently at version 3.0.1 and remains open source under the MIT License.\n\nThe repository includes the extension source, privacy documentation, tests, and release checklist:\n\nA comprehensive Chrome extension with 83 web productivity tools, including AI-powered features, a smart favorite system, converter suite, and coffee toast messages.\n\nI am especially interested in feedback on three areas:\n\nThis 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.", "url": "https://wpnews.pro/news/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools", "canonical_source": "https://dev.to/ademisler/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools-28c2", "published_at": "2026-08-01 23:28:39+00:00", "updated_at": "2026-08-02 00:09:40.874924+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["Toolboard", "Chrome"], "alternates": {"html": "https://wpnews.pro/news/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools", "markdown": "https://wpnews.pro/news/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools.md", "text": "https://wpnews.pro/news/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools.txt", "jsonld": "https://wpnews.pro/news/how-i-turned-a-cluttered-browser-workflow-into-a-chrome-extension-with-83-tools.jsonld"}}