Njectify: The day I got tired of fighting with DevTools and built my own browser IDE.
What Njectify is
I've always had this slightly annoying habit of tweaking the look and behavior of the tools and websites I use every day, especially SaaS products and legacy systems at work.
But anyone who already uses extensions to inject CSS and JavaScript knows how tedious it is. You open DevTools, make your CSS changes, copy everything over to some Stylebot, then open Tampermonkey to inject a script. The logs are scattered everywhere, the debugging experience is poor, and if the page reloads you lose part of your progress or have to redo everything. To make it worse, the user experience of these extensions has basically frozen in time. The interface is dated, the workflow is rigid, and there's no integration that makes the process genuinely pleasant.
I created Njectify out of those pains. It's a Chrome extension built on Manifest V3 that brings together everything I needed in one place. Instead of jumping from extension to extension, it offers a super fast visual inspector, an advanced CSS editor that feels a lot like WordPress's Elementor, a dedicated debug console, and a full IDE based on Monaco (the same editor behind VS Code) right inside the browser. The core idea is simple: you edit CSS and JavaScript in real time on any site, without having to open DevTools and without that annoying page flash when you save.
Use cases
If you work in design or frontend development, you know how useful it is to test adjustments to typography, colors, spacing, or even build quick prototypes directly on a client's page or an internal tool. The Quick Edit panel was designed exactly for this: visually changing margins, borders, shadows, gradients, and many other properties without writing a single line of CSS.
Another classic case is customizing sites and systems you use every day. That panel with an annoying banner taking up half the screen, or that internal system that requires dozens of repetitive clicks to do something simple. With Njectify, you can create small projects tied to specific URLs, securely store API keys, and run custom scripts to solve those little everyday frustrations.
The tool is also extremely useful for anyone working in QA or automation. You can isolate styles, inspect elements, and capture stable CSS selectors with a single click, avoiding those random class names generated by modern frameworks.
And the truth is that the limit is basically your creativity. If you know JavaScript, you can turn any page into something far more useful: build a button to download YouTube videos, set up a personal adblock, hide content containing certain words, integrate APIs, automate repetitive tasks, and much more. Instead of just consuming a site, you start adapting it exactly to your needs.
Njectify vs. the competition
I didn't create Njectify with the arrogant mindset that it came to kill Tampermonkey, Violentmonkey, Stylus, or Stylebot. These extensions are amazing, historic, and do their job very well. The point is that they were born in a different era and treat scripting and CSS as isolated hacks.
What sets Njectify apart is that it proposes an integrated workflow. The others were born specialized: Tampermonkey and Violentmonkey handle JavaScript, while Stylus and Stylebot handle CSS. To do both on the same site, you end up juggling two extensions, two editors, and two separate flows. Njectify brings it all together into a unified suite.
But just saying "it's integrated" is vague, so here's what I'm certain Njectify delivers and that the competitors, each in their own specialty, don't offer at the same time:
| Feature | Njectify | Tampermonkey / Violentmonkey | Stylus / Stylebot |
|---|---|---|---|
| JavaScript injection | ✅ | ✅ | ❌ |
| CSS injection | ✅ | partial (via GM_addStyle) | ✅ |
| Point-and-click visual editor | ✅ | ❌ | ✅ (CSS only) |
Full IDE (Monaco, the one in VS Code) | ✅ | basic editor | basic editor |
| Version history to restore snapshots | ✅ | ❌ | ❌ |
| Debug Inspector with its own log channel | ✅ | ❌ | ❌ |
| Secrets vault for API keys | ✅ | ❌ | ❌ |
| External libraries built in (React, Vue, jQuery...) | ✅ | manual @require | ❌ |
CSS hot reload with no screen flash | ✅ | ❌ | varies |
A few of these are worth highlighting. The first is the Debug Inspector: instead of cluttering the browser's main console with your scripts' logs, Njectify has its own channel that routes messages straight to the IDE's debug panel, showing exactly which file and line they came from.
Another strong point is persistence. Everything you create is stored locally in IndexedDB, organized by URL rule, with a version history that lets you restore previous snapshots of each file. The storage layer was built to be resilient: it automatically prunes the oldest history when space gets tight, and never lets a quota overflow break your work when you save.
And since the focus is real JavaScript, Njectify ships with a curated set of external libraries ready to use via CDN, like React, Vue, jQuery, Lodash, Axios, GSAP, Alpine.js, and Tailwind. Instead of hunting down CDN URLs and pasting @require by hand, you pick a library from a list and it gets injected into your script. And to close it out, the CSS hot reload (live preview) is instant and doesn't make the screen flicker, which saves a lot of patience over the course of a day.
How I used AI to help with the project
A bit of context first: AI entered my workflow as a tool, not as a crutch. I was already programming before it, so I read and review what gets generated (the important bits, at least, haha), and the technical decisions go through me before they become code (and through Codex too, haha²). It speeds up the work, but the direction is still mine.
That said, artificial intelligence was one of the main tools I used throughout development, and today it's part of my workflow the same way a code editor, a debugger, or a version control system is.
Before writing the first line of code, I started the project using a Markdown prompt architecture that I've developed over the past few months. All my projects start this way: I go through a process of briefing, interviews, requirements gathering, and planning before moving on to implementation. At its core, a good prompt is a well-written technical specification, and writing a good spec depends on knowing exactly what you want to build.
During development, I used Claude mainly as an executing agent, while Codex was the tool I used most for testing, brainstorming, code review, and architecture discussions. The final word, however, was always mine: I validated, adjusted, and often rewrote what was suggested.
AI was essential for speeding up the initial boilerplate with React 19, TypeScript, and Tailwind CSS v4, as well as helping with the more bureaucratic parts of the Chrome extensions API. Anyone who has worked with Manifest V3 knows that managing the Service Worker and communication between the extension's different contexts comes with plenty of pitfalls. We worked together to design a more robust messaging architecture and to implement end-to-end tests with Playwright, making sure script injection kept working reliably.
Since I'm quite particular about design, the entire visual identity, the design system, and the interface were built manually by me, with strong inspiration from Vercel's visual language. It's a part of the process I like to control down to the smallest detail, so I chose not to use AI for the frontend.
Development was extremely iterative. I'd describe a feature, we'd discuss implementation alternatives, refine the architecture, and adjust the code until we reached the expected result. Many decisions came out of those conversations, from optimizations in Monaco Editor's rendering to strategies for state management, messaging, and communication between the extension's different modules. Every step was validated with a combination of end-to-end and manual tests to ensure the application's stability and reliability.
In the end, AI didn't replace the development process. It sped up repetitive tasks, helped explore implementation alternatives, and served as an excellent technical partner for discussing solutions and learning along the way. The decisions about product, architecture, user experience, and design were still driven by me.
Lessons ahead
The project is running really well, but building Njectify brought me several lessons and already gave me a clear view of what needs to come next. The main lesson I took away is that ease of use can't come at the expense of the page's security and stability.
Looking ahead, my roadmap is focused on three fundamental pillars of security and technical robustness. The first priority is to fully isolate the scripts' communication channel to prevent injected code from accessing sensitive data or project secrets. The second is to build a lifecycle runtime for JavaScript scripts. Right now the CSS hot reload is perfect, but when JavaScript is updated, it accumulates on the page without cleaning up previous listeners and timers. This runtime will make sure a reload automatically clears the previous state.
I also want to unify the selector engine to make element detection even smarter and less dependent on dynamic classes, paving the way for a visual macro recorder, where the user can simply click on the page and the extension generates the corresponding script.
Permissions and why they're requested
An extension that injects CSS and JavaScript into any site naturally raises suspicion, and rightly so. That's why I make a point of being transparent about every permission Njectify requests in Manifest V3 and the reason each one exists. Nothing here is requested "just in case": if a permission is in the manifest, it's because a feature depends on it.
| Permission | Why it's requested |
|---|---|
<all_urls> (access to all sites) | It's the broadest permission and the one that scares people the most. Njectify needs to run on any address because the whole point is to let you customize whatever site you want, with no pre-approved list. In practice, it only does something on a page when there's a rule you created for that URL. Without a rule, it stays inert. |
scripting and userScripts | The heart of the tool: they allow your scripts and styles to be injected into the page in a controlled and isolated way. |
activeTab and tabs | To know which tab you're on, apply changes to the right page, and refresh tabs when you turn a rule on or off. |
storage | Everything you create is saved locally in the browser, in IndexedDB. Your scripts, styles, and settings never leave your machine through this. |
identity and identity.email | Only for the optional Google account login, in case you want to sync your projects. If you don't log in, they do nothing. |
alarms | Scheduled background tasks, such as periodically checking for script updates. |
It's worth highlighting the most sensitive point: the API keys and secrets you store in your projects. They're isolated from the injected code, and hardening that communication channel even further is, in fact, the first priority on the roadmap I mentioned above.
Finally, something that gives peace of mind to anyone installing it: Njectify only made it to the Chrome Web Store after going through Google's review process. Every permission had to be justified, and the extension was analyzed to make sure it does exactly what it claims, with no malicious behavior or improper data collection. It's not some extension loose on the internet asking you to trust a stranger's word; it went through the same rigorous scrutiny as any other officially published on the store.
Summary
At the end of the day, Njectify was born out of a personal frustration with the frontend development and page customization workflow in everyday life. With AI's help, but always guided by my own technical experience, I spent around 6 months and managed to turn that pain into a full browser IDE that brings style and behavior together seamlessly. The project still has a long road ahead with important improvements, and I really hope it can be genuinely useful to people.
Links
- Install from the Chrome Web Store: Njectify Install
- Official website: njectify.com