Why I Built VibeHeader
It started with a small frustration: sharing a few HTTP headers with a teammate was harder than it should have been. The weekend prototype that followed was quick; earning trust in the product has been the longer, more important part.
The problem was not editing headers
In the teams I worked with, testing a staging environment often began with someone sending a header configuration in chat. Sometimes it was plain text. Quite often it was a screenshot. To use it, the next person had to retype every name and value into a browser extension.
That was how a lowercase “l” became an uppercase “I” and cost us twenty minutes of debugging. Nothing was technically difficult; the handoff was simply fragile. A setup that should have been exact had been reduced to pixels and guesswork.
At the same time, the header tool I was using had grown far beyond the job I needed it to do. I also saw promotional pages open in browser profiles where ModHeader was installed; when I removed the extension from one of those profiles, the behavior stopped there. That was my own observation, not an independent security finding, but it was enough to make me look for something smaller and easier to reason about.
From frustration to a weekend prototype
I asked around for alternatives and tried a few. None matched the workflow I had in mind, so I built a first version over a weekend. The goal was deliberately narrow: edit request headers, keep the interface quiet, and turn a configuration into a link that another person could review and import.
The sharing model became the center of the product. A VibeHeader link stores its configuration in the URL fragment—the part after #c=. Browsers do not send that fragment to the VibeHeader server, so the preview and import can happen locally. The complete link still contains the configuration, which is why it should be shared through a trusted channel, but VibeHeader does not need to receive or store it.
That solved the original problem: no retyping, no screenshot ambiguity, and no account or shared backend required.
About the name—and the role of AI
The name VibeHeader is intentionally a little playful. The first version was also built in the spirit of what people now call “vibe coding”: I used an AI coding assistant to move quickly from an idea to a working prototype.
But that describes how the prototype started, not the standard the product is held to. I have a background in computer science and have spent years building software products. That does not make every decision automatically correct; it means I understand that decisions about scope, architecture, permissions, security review, testing, and releases are mine to make—and mine to be accountable for. AI can accelerate implementation. It cannot take responsibility for the result.
VibeHeader is open source so those choices can be inspected instead of merely promised. Open source is not, by itself, a guarantee of quality. It does make the code, permissions, changes, and mistakes visible, and gives users a concrete way to question or verify what the product does.
The product grew, but the job stayed focused
The first version handled a single, simple header setup. As more people used it, the requests were less about adding unrelated capabilities and more about making the same workflow safe at a larger scale: keeping projects separate, limiting a header to the right requests, and sharing the scope along with the values.
That led to Profiles and Request Filters. You can now keep different projects and environments apart, scope rules to a host, URL prefix, wildcard, or regular expression, test a URL before relying on the rule, and include valid filters in a share link. The quick path is still the same: add one header and turn it on. The additional controls only appear when the workflow needs them.
The standard is not “never add features.” It is that every feature should earn its place by making header work more precise, easier to share, or safer to operate.
Then ModHeader was removed
In July 2026, Google flagged ModHeader as malware and Chrome disabled it for many users; Microsoft removed it from the Edge Add-ons store. Independent researchers reported that version 7.0.18 included a hidden SDK that collected visited domains without notice or an opt-out.
I did not see that as a victory for VibeHeader. Browser extensions in this category receive powerful access, and the incident was a reminder that a clean interface is not enough. Users need to understand the permissions an extension asks for, what data it handles, how it is funded, and whether its behavior can be audited.
I wrote a separate account of the ModHeader incident, including sources and VibeHeader’s permission model. If you had the affected version installed, start with the cleanup and self-check guide before migrating any configuration.
What I am committing to
VibeHeader will remain a focused header tool: no ads, no behavioral tracking, and no business model that depends on quietly monetizing browser access. We will keep the source available, explain the permissions we need, and treat security and privacy work as part of product quality rather than a line in the marketing copy.
The promise is intentionally modest. VibeHeader will not be perfect, and “built by an experienced developer” is not a substitute for evidence. What I can promise is that we will make the important decisions understandable, keep the implementation inspectable, respond to issues, and take responsibility for the software we publish.
That is what the name means to me now: the project may have started with a weekend vibe, but it has to earn trust release by release.