DEV Community: Pavel Borisov

I tested the existing Chrome tab audio recorders. I had to build a proper one

Pavel Borisov — Sat, 14 Nov 2026 05:23:07 +0000

The first version of this article was written for habr, a Russian technology publication, but its moderators rejected it for “using AI to write and edit the text.” So I rewrote it myself. I had honestly tried to protect readers from my own literary talent, but that attempt failed. You will now have to endure my jokes, questionable metaphors, and occasional bouts of verbosity. You can still close the page, though. You have been warned.

Now to the point. Some time ago, I needed a Chrome extension that could record audio from a browser tab. The task looked so simple that I had no intention of developing anything. Surely the Chrome Web Store already contained dozens of ready-made solutions. Pick one, press Record, and carry on with your life.

I installed several extensions, tested what they could do, and read their user reviews. Gradually, I came to the conclusion that the world apparently needed my intervention.

Some extensions were too basic. Others offered useful features but did not always deliver them reliably. Some lacked automation, some raised uncomfortable questions about whether a recording would survive, and some imposed limits whose purpose I could not understand. I will go through those problems below. In the end, I decided to build my own extension and called it Pulse: Free Tab Audio Recorder.

At first, I planned to make a convenient recorder with a few extra features. Then more ideas appeared. Then a few more. Eventually it became clear that the original plan could be discarded. That is a familiar development story: if someone claims their finished product matches the original specification perfectly, they may simply not have started building it yet.

An hour of recording, and nothing was saved. Wonderful

I will start with the kind of software that irritates me most: software that merely looks as if it is working. Imagine recording a one-hour lecture. The extension shows a recording indicator, the timer counts every minute correctly, and everything appears fine. An hour later, you click Stop and expect a file. Instead, you get an error. Or an export that never finishes. Or a browser crash. This is particularly delightful when the lecture was a one-off live stream.

At first, I assumed failures like this must be rare. Then I read the reviews.

The last review felt especially familiar. Keeping the entire recording until the very end and then trying to save it in one operation is, to put it mildly, risky. Until the user presses Stop, they have no way of knowing whether the recording can actually be saved.

The program holds an hour of captured audio hostage and promises to hand it over only after you click Stop. If the browser crashes first, the hostage is gone. Even meeting the captor’s demands does not guarantee a happy ending: according to the reviews, the export itself can fail too.

I decided not to leave users negotiating with kidnappers. Pulse saves audio locally in small chunks while recording is still in progress. If the browser closes unexpectedly, everything already written to disk remains there. Counter-Terrorists Win.

A little about the architecture

First, I had to deal with Manifest V3. Chrome may stop an extension’s background service worker whenever it considers the worker inactive. Entrusting a multi-hour recording to it would therefore be optimistic: eventually the browser might simply decide that the worker is no longer needed.

In Pulse, the service worker coordinates the process. It obtains access to the tab’s audio stream, starts and stops sessions, and passes commands around. The audio itself is handled in a special hidden document that Chrome allows extensions to create for tasks like this.

Chrome tab → Audio capture → Offscreen document → Encoding → IndexedDB

Audio travels from the tab into the offscreen document, where it is processed and encoded in the selected format. Finished chunks are written sequentially to a local IndexedDB database. If Chrome terminates unexpectedly, the data already written to disk does not disappear with the recording process.

Each chunk is stored together with its position and the current recording state. The audio data and its metadata are committed in the same transaction. This prevents Pulse from marking a chunk as saved when its write operation never actually completed.

The exact process depends on the format. For WebM, the browser itself provides chunks of encoded audio roughly once per second. MP3 and WAV use a separate audio pipeline and encoder.

I consider protection of already captured data a basic property of a recorder, not a premium feature for which users should thank the developer with tears in their eyes. Judging by some reviews, however, there is apparently something to be thankful for.

Twenty minutes ought to be enough for anyone

Another thing I discovered while studying competing extensions was the recording-duration limit.

Twenty minutes. I tried to imagine a situation in which this would make sense as a universal limit. It is too long for a song, too short for a lecture, and rather absurd for a webinar. Apparently all useful knowledge stops at minute twenty-one.

I did not add an artificial duration limit to Pulse. Need five minutes? Fine. Three hours? Also fine. Record as much as your computer can handle. The real limits are the available storage and the computer’s resources.

If storage runs out, that is where my powers end. I can write software, but I have not yet learned to conjure extra gigabytes out of thin air. Pulse can at least give you advance warning: when Chrome estimates that less than 500 MB remains available to the extension, Pulse displays a warning and estimates how many minutes are left at the current format and quality.

Can it do that by itself?

I am a fairly lazy person—in the sense that I dislike performing actions a computer can handle perfectly well on its own. If I need to record a lecture, I do not want to keep checking whether it has started, whether playback has stopped, whether a long pause has begun, or whether it is time to finish the recording. The machine has a processor. Let the robots handle the repetitive work.

That is why Pulse includes several kinds of automation.

You can delay the start by a few seconds or tell Pulse to begin only when sound appears in the tab. Recording can also stop automatically after a chosen duration, when the page changes, or after a prolonged period of silence.

There is also Smart Pause. It can pause a recording automatically in two ways.

The first responds to silence: when sound disappears for the chosen interval, recording pauses. When sound returns, recording resumes.

The second follows the media player. If a user pauses a YouTube video, Pulse pauses the recording too. When playback resumes, the recording follows immediately. Pulse does not have to wait for the silence detector’s delay because it reacts directly to the player state.

Unfortunately, the same synchronization logic cannot work equally well on every website. Media players differ, and some require site-specific handling. Pulse currently supports this behavior on YouTube, VK, and Instagram. I can add other websites and social platforms if there is enough demand.

Disconnecting the internet, because why not?

After I implemented automatic pausing and resuming, one beta tester decided to see what happened when the internet connection dropped. He opened a music video on YouTube, started recording, and disconnected the network. Playback stopped. Then he restored the connection, waited for the video to continue, and finished the recording.

He found a problem: the join between the two audio segments was clearly audible. He reported it, and I had to investigate.

Simply pausing the recorder at the same time as the player was not enough. A pause event and the actual end of audible output do not always occur at exactly the same moment. The player may already report that it has stopped while a small amount of audio still remains in the stream. If recording stops immediately, the end of a word or musical phrase gets cut off.

Resuming has a similar problem. The player may already be running while the sound reaches the extension slightly later. Joining two segments at unfortunate sample positions can also create a sudden amplitude jump that the ear hears as a click.

I had to work on the boundaries. For MP3 and WAV, Pulse retains a short tail of recent audio instead of cutting the stream as soon as it receives a pause event. It continues analysing the signal until the sound has actually faded. When recording resumes, Pulse checks the beginning of the next segment and, when necessary, applies a very short crossfade.

Automatic silence detection created a separate issue. A detector needs a little time to notice that sound has appeared. Without compensation, the beginning of a word or musical note may be lost. Pulse therefore keeps a short pre-roll buffer of the latest input. When sound appears, that buffered audio is included so the beginning is preserved.

WebM required a different approach because the audio has already been encoded and the join cannot be repaired at the sample level in the same way. I introduced a short delay into the recording pipeline and synchronized the pause and resume commands with it. This places the boundaries closer to the actual beginning and end of the sound.

This took a fair amount of trial and error: change the algorithm, record test fragments, listen closely to every join, and change it again.

After the fixes, the tester repeated the network-disconnection experiment. This time he could not tell where the join was. He tested it on music, where this kind of defect is especially noticeable.

Audio quality, or why some developers add a fireplace

The next group of reviews puzzled me. Users complained about crackling, clicks, and other unwanted sounds in their recordings.

I have a theory. Perhaps the developers wanted to make listening more comfortable: an evening, a cup of tea, favourite music, and a fireplace crackling quietly in the background. Unfortunately, their users failed to appreciate the artistic vision.

I decided not to repeat that bold experiment. If someone wants the sound of a fireplace, they can open the appropriate YouTube video themselves. I spent a great deal of time on audio quality in Pulse, including the removal of unwanted clicks around pause and resume boundaries.

Here is another review:

For this user, 128 kbps was not enough. The extension also stopped offering MP3 for long recordings and left WebM as the only option.

Another user specifically needed WAV:

Pulse therefore supports three formats: MP3, WAV, and WebM. MP3 can be recorded at up to 320 kbps. WAV is available for people who need lossless PCM audio. MP3 is useful when file size and compatibility matter. WebM is one of the formats Chrome can record directly without an additional encoder.

Of course, saving an already compressed source as WAV will not restore information that was previously lost. Nor will 320 kbps MP3 turn a poor source into a studio recording. At least the extension does not need to make the sound worse.

Naming a file so you can find it later

Another category of requests seemed entirely reasonable.

A file name looks like a minor detail until you record browser audio regularly. A month later, you have several dozen files, all called something like this:

recording_1.mp3
recording_2.mp3
recording_final.mp3
recording_final_final.mp3

The last one naturally contains anything except the recording you are looking for.

Pulse lets users configure file-name templates. A name can include information about the recording so that files are easy to distinguish later. This becomes particularly useful when recording several tabs at once, which brings me to the next feature.

A developer can spend a month refining an audio algorithm, and the feature that delights users most may still be sensible file names. Fortunately, one is allowed to be proud of both.

One tab is good. Three are better

Some Pulse features appeared only after development had already begun. Recording several tabs simultaneously was one of them. The original workflow was ordinary: open a tab, click Record, and receive one audio file.

Then I needed to capture sound from several tabs at once, so I added it. Pulse can now run multiple independent recordings in parallel. Every tab is saved separately and produces its own audio file.

Under the hood, each tab gets its own recording session with an audio stream, encoder, timers, and settings. All sessions still run inside a single offscreen document because Chrome does not allow an extension to create a separate one for every tab.

I also had to ensure that simultaneous commands from different tabs could not interfere with each other. If two sessions report state changes at nearly the same time, one must not overwrite the other. Pulse therefore serializes those state updates.

Recording several tabs revealed another problem. If every tab plays through the speakers, working at the computer becomes difficult—especially when each speaker is talking in a different language. So I added the option to record a tab without hearing it through speakers or headphones.

A Chrome behavior made this possible. When an extension captures tab audio, the browser stops routing that audio to the output device automatically. If the user should still hear it, the extension must route the captured stream back to the speakers itself.

Pulse makes that routing optional. If the user wants to listen, the audio goes to the speakers or headphones. If not, monitoring stays off while recording continues. The setting does not change the quality of the saved audio.

As a result, you can record a lecture in one tab and listen to music in another. No microphone is involved: Pulse receives the audio directly from the browser tab, so room conversations, keyboard noise, and other domestic sound effects do not enter the file.

The interface evolved too. Extensions normally open in a small popup, which is enough for a simple action. With several recordings running, repeatedly reopening that popup becomes inconvenient. Pulse can therefore be pinned to Chrome’s side panel and remain visible while the user works.

An interface that does not require another degree

Building an extension with two buttons is easy: Start and Stop. Add an attractive icon, describe the interface as “intuitive,” and declare the task complete.

The opposite extreme is equally available: implement dozens of features, place every setting on one screen, and create something halfway between an aircraft cockpit and a nuclear power station control room.

I did not want users to choose between simple but primitive and capable but impenetrable.

My brief to the designer was therefore straightforward: a newcomer should understand how to record audio quickly, while an experienced user should still be able to find the advanced controls. I think we came reasonably close.

Evaluating your own interface is difficult, of course. I helped design it, discussed every decision, and requested changes, so every button appears obvious to me.

Then a user arrives and looks for an obvious feature in a place you never imagined. A tester finds a path through the interface that nobody on the team considered. If the product breaks, the interface did not protect the user well enough.

The first temptation is to blame the person who could not find the button directly in front of them. I am not going to pretend that thought never occurs to me.

Eventually, however, the unpleasant conclusion remains: when users do not understand an interface, the developer or designer has probably failed somewhere—especially when several users struggle in the same place.

That is why feedback from people seeing Pulse for the first time is particularly valuable.

The interface is currently available in nine languages. Pulse was designed for more than a Russian-speaking audience from the beginning.

Why record audio from a local video?

While reading reviews of other extensions, I found another request.

People sometimes need audio not only from websites but also from local files opened in the browser. Perhaps they have an MP4 video and only need its audio track. The usual solution is a separate converter, but the user can also open the video in Chrome, start playback, and record the sound with Pulse.

Chrome requires the user to grant the extension access to local file URLs separately. That is a browser restriction rather than a Pulse setting.

This does not replace a proper converter. Recording happens in real time, so extracting audio from a two-hour video still takes two hours. For a small clip and a one-off task, however, it works perfectly well.

ChatGPT as a voiceover tool

Some time ago, I needed voiceovers for video tutorials about another extension I built: BlockIt, which hides or removes unwanted elements from websites. Incidentally, making those tutorials reinforced another lesson: it is better to make software understandable from the beginning than to make the developer write instructions and the user study them.

Back to the voiceover. I needed the tutorials in several languages. I translated the scripts with ChatGPT and then decided to use its Read Aloud feature. ChatGPT—and DeepSeek as well—can read an assistant response aloud. I only needed a way to save the resulting audio.

That is where Pulse became useful. I started Read Aloud, captured the tab audio, and received a ready-to-edit file. I then used it while assembling the tutorial videos.

This allowed me to avoid a specialised paid text-to-speech service.

A feature I didn't even know I had

I had planned to stop after implementing the existing features, but while collecting material for this article I found another interesting review.

The request concerns picture-in-picture mode, where a video continues in a small always-on-top window while the user works in another application. The reviewer could not use that mode while recording audio.

Naturally, I decided to check whether Pulse had the same problem. It turned out that picture-in-picture already worked while recording. For once, I had discovered a feature that didn't require me to write another line of code.

Free, paid, and available to bargain hunters

I also found this review while studying competing extensions:

The frustration is understandable. Paying $30 for software that barely differs from free alternatives is hard to justify—especially if its main feature works only intermittently. At that point, even a coconut-milk latte begins to look like the more sensible investment.

I chose a freemium model for Pulse. The free version remains a useful recorder in its own right, while Pro adds controls that save time and automate repetitive work.

Pulse Free

Core recording, free and without a duration limit

Record one tab to MP3, WAV, or WebM
Quality up to 256 kbps
Chunked saving while recording is in progress
Delayed start using a timer
Preset stop intervals: 30 minutes, 1 hour, or 2 hours
Buffering time is excluded from the recording automatically

Pulse Pro

Automation and several independent recordings

Record several tabs simultaneously
Record without playing the tab through speakers or headphones
Smart Pause based on silence or the media-player state
Start recording when sound appears
Custom stop conditions and exact durations up to 24 hours
Custom file-name templates and quality up to 320 kbps

Get Pulse Pro free for life

The first 1,000 users to activate Pulse Pro receive a free lifetime licence, with no subscription or bank card required.

To claim yours, install Pulse, click “Get Pulse Pro free” in the extension settings, and sign in with Google. Activation takes about a minute.

Note: Installing Pulse alone does not reserve a licence. You need to complete the activation.

Get Pulse

Instead of a conclusion

The result is a Chrome extension that records tab audio to MP3, WAV, or WebM without an artificial duration limit. It can capture several tabs at the same time, save each one to a separate file, and do so without forcing the user to listen to every recording.

I paid particular attention to automation. Pulse can start and stop under selected conditions, skip prolonged silence, and follow playback on YouTube, VK, and Instagram. To prevent an hour-long recording from disappearing after an unexpected browser failure, Pulse writes audio to disk in small chunks while recording is still in progress.

I tried to fit all of that into an interface that does not require a manual. Users will decide how successful that attempt was.

Could I have built something simpler? Absolutely.

Could I have spent less time developing it? Without question.

But then it would have been just another extension that records audio.

I wanted to build a proper one.

You can explore Pulse, see its interface, and learn more about its features on the project page: Pulse on FormaCode.dev.

I Built a Chrome Audio Recorder Extension — Meet Pulse

Pavel Borisov — Wed, 28 Oct 2026 04:10:06 +0000

Recording audio from a browser tab sounds like a simple task. Open an extension, click Record, and save the file.

But what happens when you pause a video, need to record several tabs, or your browser crashes after two hours of recording?

These are some of the problems I wanted to address when I started developing Pulse: Free Tab Audio Recorder, a Chrome extension for recording audio directly from browser tabs.

Before building it, I spent time reading reviews of existing audio recording extensions in the Chrome Web Store. I was particularly interested in negative reviews and feature requests: what frustrated users, what made recording unnecessarily complicated, and what they wished their recorders could do automatically.

That research helped shape Pulse.

Recording Audio Shouldn't Mean Editing Out Silence Later

Imagine you're recording a two-hour online lecture.

You pause the video several times to take notes, answer a message, or grab a coffee. But your audio recorder keeps running.

When you finally save the recording, it contains long stretches of silence that you now have to remove manually.

I wanted Pulse to handle these situations automatically.

Start recording when audio begins

Instead of manually coordinating the recorder with the audio player, you can configure Pulse to begin recording when sound starts playing in the tab.

This is particularly useful when you're waiting for a live stream or another audio source to begin.

Pause when playback pauses

If you're recording a YouTube video and pause playback, Pulse can automatically pause the recording too.

When playback resumes, recording continues.

This avoids unnecessary silent sections without requiring you to manage two sets of controls.

Stop when playback ends

Pulse can also stop recording automatically when a video or audio track finishes.

You don't have to keep checking whether the content has ended.

Detect extended silence

Not every silence comes from pressing a Pause button.

Some streams, lectures, and recordings contain naturally occurring periods without sound. Pulse's smart pause feature can detect extended silence and pause recording automatically.

These automation features help produce recordings that need less editing afterward.

What If Chrome Crashes During a Long Recording?

This was another problem I wanted to address.

Imagine recording a webinar for several hours, only to have the browser close unexpectedly just before you click Stop.

If the recorder depends on a final save operation, you risk losing everything.

Pulse takes a different approach: it saves recorded audio data locally as recording progresses, rather than waiting until the very end.

If Chrome closes unexpectedly or the computer shuts down, the audio already captured remains available. When you reopen the extension, Pulse can finalize the interrupted recording.

Of course, audio that was never captured cannot be recovered. But an unexpected shutdown shouldn't mean losing the entire recording.

I also decided not to impose artificial recording time limits. Whether you're recording a short audio clip or a long lecture, Pulse doesn't stop simply because you've reached a preset duration.

Recording Multiple Browser Tabs at Once

Sometimes one recording isn't enough.

For example, you might want to capture audio from two simultaneous live streams, or record several independent audio sources without combining them.

Pulse supports recording multiple Chrome tabs simultaneously.

Each tab has its own recording controls, and each recording is saved separately.

You don't have to mix several audio sources into one file or run multiple instances of a recording application.

How to Record Audio from Chrome Without a Microphone

Another important distinction is where the audio comes from.

Pulse captures audio directly from the browser tab, rather than recording sound through your microphone.

That means the recording doesn't include your keyboard clicks, conversations in the room, computer fan noise, or other sounds around you.

With Pulse, you can even mute the tab's audio output so you don't have to listen while recording. Pulse can continue capturing the tab's audio without playing it through your speakers or headphones.

This is useful when recording a long lecture, webinar, podcast, or stream while working on something else.

MP3, WAV, WebM — And Local Storage

Different recordings call for different formats.

Pulse supports:

MP3, with bitrates up to 320 kbps.
WAV, for uncompressed audio.
WebM, for another browser-friendly recording option.

All recordings are stored locally on your computer. Pulse doesn't upload your audio to a remote server for processing.

Can You Save Audio from YouTube or Instagram?

Looking for a way to download music from YouTube, save audio from Instagram videos, or convert online videos to MP3?

Pulse offers an alternative: instead of downloading the original file, it records audio directly from your Chrome tab and saves it as MP3, WAV, or WebM.

You can use it to record YouTube audio, capture sound from Instagram clips, online radio, and other websites — without microphone noise or unnecessary silence.

An Unexpected Use Case: Creating AI Voiceovers

One way I've used Pulse myself is to create voiceovers for a video in several languages.

I already had translated scripts, but I didn't want to pay for an additional text-to-speech service.

So I tried a different approach.

I sent the translated scripts to ChatGPT, asked it to repeat the text, and used its Read Aloud feature to generate the speech.

Then I recorded the audio directly from the browser tab using Pulse.

It worked. I got the voiceovers I needed without introducing another paid tool into my workflow.

This is just one example. The same approach can be useful for capturing AI-generated speech, recording online lessons, saving audio from music videos, or keeping other browser audio you have permission to record.

Free Recording and Advanced Features

I want Pulse to remain useful without requiring a paid license.

The free version covers essential recording needs: capturing audio from one tab without time limits, choosing an output format, using basic recording controls, and recovering already recorded audio after unexpected crashes.

Pulse Pro adds:

Simultaneous recording from multiple tabs.
Recording without playing tab audio through your speakers or headphones.
Smart pause that skips long periods of silence.
MP3 quality up to 320 kbps (compared to 256 kbps in the free version).
Custom recording timers and automatic stopping when the page changes or silence continues.
Custom filename templates.

Get Pulse Pro Free for Life — Limited to 1,000 Licenses

To celebrate the launch, I'm giving away 1,000 free lifetime Pulse Pro licenses to the first users who activate them.

Important: Installing Pulse does not automatically activate your Pro license. It's a separate step that takes less than a minute:

Open the extension's settings and go to the License section.
Follow the link to the license activation page.
Sign in with your Google account.
Click Activate.

That's it! Your lifetime Pro license is activated, with all Pro features unlocked and no subscription or future payments.

The offer is limited to the first 1,000 activations, so don't forget to claim your license while it's still available.

Try Pulse and Share Your Feedback

Pulse is an independent project that I'm continuing to develop.

Many of its features came from reading what users were asking for in reviews of other browser audio recorders. I plan to keep listening to that feedback as I improve the extension.

If you regularly record webinars, online lectures, podcasts, live streams, or AI-generated speech, I'd be interested to know which recording features matter most to you.

Try Pulse and activate your free lifetime Pro license

Feedback, bug reports, and feature suggestions are welcome.

BlockIt: Flexible Web Element Blocking with Full Control Over Rules

Pavel Borisov — Fri, 23 Oct 2026 01:27:33 +0000

Many websites contain elements you'd rather not see: intrusive banners, pop-ups, advertisements, or simply unnecessary parts of the interface.

Modern ad blockers not only use predefined filter lists but also allow users to manually select elements to block. In most cases, that's enough: select an element, create a rule, and it no longer gets in your way.

But sometimes things are more complicated.

For example, a blocked element may reappear after a page reload because its classes or position in the DOM have changed. Or an automatically generated rule may affect other elements that the user never intended to block.

In these situations, it's important not only to specify which element should be blocked, but also to determine exactly which properties should be used to find it.

To address these challenges, I developed BlockIt — a free Chrome extension that lets users create flexible rules for blocking web page elements.

BlockIt supports standard CSS selectors, XPath, and its own extended syntax, which can take additional properties of elements and their surroundings into account: text, attributes, classes, DOM position, relationships with other elements, and much more.

You can also create and customize rules without knowing selector syntax or specialized expressions. BlockIt provides tools for choosing relevant element properties, excluding unstable attributes and classes, combining search conditions, and checking whether a rule continues to work after a page reload.

This makes BlockIt useful both for advanced users and web developers who need detailed control over element matching, and for anyone who has encountered a particularly annoying element that cannot be reliably removed using conventional methods.

The main idea behind BlockIt is to give users the tools to create precise, reliable rules while letting them decide which properties should be used to identify elements for blocking.

Why a Regular CSS Selector Isn't Always Enough

Imagine a page containing several similar blocks. You need to block just one of them without affecting the others.

Chrome DevTools lets you automatically copy the CSS selector of a selected element. For example:

#app > div:nth-child(2) > div:nth-child(3)

This selector finds a div element that is the third child of another div. That parent div, in turn, must be the second child of the element with the ID app.

The selector may work correctly on the current page. But if the website's developers add another container or change the order of elements, it may start matching a different block or stop working entirely.

Another common problem is dynamically generated classes.

For example, an element might look like this on one page load:

<div class="banner_a8f32">

And like this on the next:

<div class="banner_c91e4">

The selector .banner_a8f32 matches an element with the class banner_a8f32. Once the class changes, it can no longer find the intended block.

Sometimes choosing a more stable CSS selector is enough. But there are situations where precise matching requires additional properties: text content, the number of attributes, position relative to other elements, or a combination of several conditions.

BlockIt provides additional capabilities for exactly these situations.

What Is a BlockIt Rule?

Before exploring the different ways to create rules, it's worth clarifying the terminology.

In the broad sense, a BlockIt rule is a description of how to find page elements that should be blocked.

Several methods can be used to find elements:

CSS selector — the standard syntax for selecting DOM elements.
XPath — an expression language for locating elements within a document's structure.
BlockIt syntax — the extension's own syntax, which adds capabilities beyond standard CSS selectors.

Therefore, even an ordinary CSS selector becomes a BlockIt blocking rule when added to the extension.

However, the extension's interface also uses the term "BlockIt Rule" in a narrower sense — to refer specifically to an expression written using BlockIt's own syntax, as opposed to a standard CSS selector.

For example, after creating a rule, you may see a label such as "CSS Selector" or "BlockIt Rule". In this context, these labels indicate the syntax being used.

Several Ways to Create a Rule

I wanted BlockIt to be suitable for both simple tasks and situations that require detailed control over element matching.

That's why the extension offers several ways to create rules.

1. CSS Selector

The simplest approach is to select an element in Chrome DevTools, copy its CSS selector, and paste it into BlockIt.

But DevTools isn't required: you can write a CSS selector manually or edit an existing one.

For example:

div.notice[data-type="promo"]

This selector matches div elements that have the class notice and a data-type attribute with the value promo.

The extension displays the number of matching elements. This helps you check whether the rule affects any unintended elements.

You can choose one of two actions for matched elements:

Remove — completely remove the element from the DOM, usually freeing up the space it occupied.
Hide — make the element invisible while preserving the space it occupies on the page.

The second option is useful when removing an element disrupts the page layout.

2. XPath

BlockIt also supports XPath expressions.

For example:

//div[@data-type='promo']

This expression finds div elements whose data-type attribute has the value promo, regardless of their position in the document.

XPath provides additional ways to locate elements and navigate the DOM.

However, XPath does not guarantee stability by itself. If an expression relies on changing attributes or element positions, it can also stop working.

3. Quick Rule from HTML

One of the most convenient ways to create rules is the Quick Rule tool.

Instead of providing a selector, you can simply copy the HTML of the desired element from Chrome DevTools and paste it into the corresponding field in BlockIt.

The extension parses the HTML and lets you choose which properties should be used for matching.

For example, suppose the original element looks like this:

<div id="cmpbox" class="cmpbox_a8f32" role="dialog">

If the class cmpbox_a8f32 is dynamically generated, you can exclude it and keep only the attributes id="cmpbox" and role="dialog".

Then simply click the "Add Rule" button.

This way, users can decide which attributes and classes to include without having to write a selector manually.

Rule Builder

For more complex cases, BlockIt includes a Rule Builder.

It allows you to define element-matching conditions through a graphical interface without requiring knowledge of CSS, XPath, or BlockIt's own syntax.

The Rule Builder can take into account not only an element's own properties but also its surroundings.

For example:

HTML tag, classes, and attributes;
text content, including substring matching and regular expressions;
number of classes and attributes;
position among sibling elements;
properties of parents, ancestors, descendants, and siblings;
distance to a sibling and the absence of certain related elements.

These conditions can be combined.

Suppose a page contains several elements with identical classes, but the one you need is inside a container with a particular attribute. Instead of relying on the element's position, you can use properties of its surrounding elements.

Or, if classes keep changing, you can try identifying the element by its text and other more stable characteristics.

The Rule Builder displays a human-readable description of the generated rule. This helps users understand which properties are involved in matching, even if they aren't familiar with selector syntax.

Testing After a Page Reload

Finding the correct element once doesn't necessarily mean you've created a reliable rule.

On dynamic websites, it's important to make sure the rule continues to work on subsequent page loads.

That's why the Rule Builder includes a test after page reload feature.

It lets you compare the number of matching elements before and after reloading the page.

If matches disappear or their number changes, this may indicate that the selected conditions are unstable.

You can adjust the rule and run the test again.

Of course, matching the same number of elements doesn't guarantee that the rule will always find exactly what you intended. But this test helps identify certain problems while the rule is still being created.

BlockIt's Extended Syntax

Not all conditions available in the Rule Builder can be expressed using standard CSS selectors.

For example, standard CSS does not support matching elements by arbitrary text content or checking the number of attributes an element has.

For these situations, I developed BlockIt's own syntax, which extends the capabilities of CSS selectors.

For example, you can match elements by their own text while ignoring text inside nested elements, check the number of classes and attributes, or define additional conditions involving surrounding elements.

If the conditions selected in the Rule Builder can be expressed using standard CSS, the result will be an ordinary CSS selector.

If additional capabilities are required, the Rule Builder generates a "BlockIt Rule" — here, the term is used in its narrower sense, meaning an expression written using the extended syntax.

In either case, the user gets a ready-to-use rule for finding and blocking elements.

And there's no need to learn BlockIt's syntax: complex conditions can be configured directly in the Rule Builder.

For those who prefer writing expressions manually, the BlockIt syntax documentation is also available.

When a Regular Element-Blocking Tool Isn't Enough

Imagine a situation: an annoying element appears on a website, and the standard filters of your installed ad blocker don't remove it.

You decide to block it manually using the ad blocker's built-in element picker. You select the unwanted block, create a rule, and the element disappears.

But after reloading the page, it comes back.

The reason may be that the automatically generated selector relied on a dynamically generated class or a changing DOM structure.

In this situation, BlockIt offers several possible approaches.

You can manually choose a more stable CSS selector, use XPath, or create a more complex rule with additional conditions through the Rule Builder.

For example, you can stop relying on a dynamic class and instead use the element's text, attributes, or properties of surrounding containers.

You can then test the rule in the Rule Builder after reloading the page.

This can help block certain complex elements for which an automatically suggested selector wasn't reliable enough.

Of course, similar problems can be solved using other tools. For example, uBlock Origin supports advanced cosmetic filters that can express complex matching conditions.

What makes BlockIt distinctive is its combination of multiple ways to create rules, detailed control over matching conditions, and tools that make complex rules accessible without requiring users to learn specialized syntax.

At the same time, the extension doesn't promise to automatically find the perfect properties for every element.

A rule's reliability depends on the characteristics of the particular page and how well its matching conditions are chosen. BlockIt provides the tools to tackle this problem, but the final choice remains with the user.

Working with iframes and Shadow DOM

Some page elements are not located in the main DOM document.

For example, content may be placed inside an iframe or use Shadow DOM.

This introduces additional challenges when finding and blocking elements.

BlockIt supports applying rules inside iframes and Shadow DOM, although different matching methods have certain technical limitations.

In particular, XPath cannot cross a Shadow DOM boundary. For such cases, rules based on CSS or BlockIt's extended syntax can be used.

In addition, BlockIt's own syntax provides special conditions related to iframes and Shadow DOM.

This expands the possibilities for finding elements in complex web page structures.

How BlockIt Relates to StableHTMLFinder

In my previous article about StableHTMLFinder, I discussed the problem of unstable CSS selectors and how to analyze DOM changes across page loads.

StableHTMLFinder and BlockIt solve different but related problems.

StableHTMLFinder helps identify which elements and properties remain stable across repeated page loads.

BlockIt lets you use those properties to find and block unwanted elements.

For example, if a block's classes keep changing, you can first analyze the page using StableHTMLFinder, identify stable properties of the element itself or its surroundings, and then use them to create a rule in BlockIt.

StableHTMLFinder can also generate CSS selectors and expressions using BlockIt's syntax, which you can copy into the blocking extension.

However, using both tools together is entirely optional: BlockIt works independently.

Managing Rules

Once you've created a rule, you can also manage it.

BlockIt lets you disable rules without deleting them, organizes them by website, and supports exporting and importing settings.

This is useful when you've accumulated many rules for different websites.

All rules are stored locally in the browser and are not sent to a server.

BlockIt's source code is open and available on GitHub under the BSD-3-Clause license.

Try BlockIt

BlockIt is a free Chrome extension.

If you'd like to try it yourself, visit the official BlockIt page, where you'll find a link to install the extension from the Chrome Web Store.

I've also prepared a detailed guide with examples and screenshots to help you explore the extension's features. It covers different ways to create rules, from a simple CSS selector to the Rule Builder with complex conditions.

If you've encountered elements that were difficult to block using ordinary CSS selectors, I'd be interested to hear how you approached the problem.

BlockIt: гибкая блокировка элементов веб-страниц с полным контролем над правилами

Pavel Borisov — Thu, 22 Oct 2026 19:44:23 +0000

На многих сайтах встречаются элементы, которые хотелось бы убрать: навязчивые баннеры, всплывающие окна, рекламные блоки или просто ненужные части интерфейса.

Современные блокировщики рекламы позволяют не только использовать готовые списки фильтрации, но и самостоятельно выбирать элементы для блокировки. В большинстве случаев этого достаточно: выбрал элемент, создал правило — и он больше не мешает.

Но иногда всё оказывается сложнее.

Например, после обновления страницы заблокированный элемент появляется снова, потому что его классы или положение в DOM изменились. Или автоматически созданное правило затрагивает другие элементы, которые пользователь вовсе не собирался блокировать.

В таких ситуациях важно не просто указать, какой элемент нужно заблокировать, но и определить, по каким именно признакам его следует находить.

Для решения подобных задач я разработал BlockIt — бесплатное расширение для Chrome, позволяющее создавать гибкие правила блокировки элементов веб-страниц.

В BlockIt можно использовать обычные CSS-селекторы, XPath или собственный расширенный синтаксис, который позволяет учитывать дополнительные характеристики элементов и их окружения: текст, атрибуты, классы, положение в DOM, связи с другими элементами и многое другое.

При этом создавать и настраивать правила можно без знания синтаксиса селекторов или специальных выражений. BlockIt предоставляет инструменты, позволяющие выбирать нужные признаки элементов, исключать нестабильные атрибуты и классы, комбинировать условия поиска и проверять, продолжает ли правило работать после обновления страницы.

Таким образом, BlockIt может быть полезен как опытным пользователям и веб-разработчикам, которым нужен подробный контроль над поиском элементов, так и тем, кто просто столкнулся с особенно назойливым блоком, который не удаётся надёжно убрать обычным способом.

Главная идея BlockIt — дать пользователю инструменты для создания точных и устойчивых правил, сохранив возможность самостоятельно решать, какие признаки использовать для блокировки.

Почему обычного CSS-селектора иногда недостаточно

Представим, что на странице есть несколько похожих блоков. Нужно заблокировать только один из них, не затрагивая остальные.

Chrome DevTools позволяет автоматически скопировать CSS-селектор выбранного элемента. Например:

#app > div:nth-child(2) > div:nth-child(3)

Этот селектор ищет элемент div, который является третьим дочерним элементом другого div. Тот, в свою очередь, должен быть вторым дочерним элементом элемента с идентификатором app.

На текущей странице он может работать правильно. Но если разработчики добавят новый контейнер или изменят порядок элементов, селектор может начать находить другой блок либо вообще перестать работать.

Другая распространённая проблема — динамически генерируемые классы.

Например, при одной загрузке страницы элемент выглядит так:

<div class="banner_a8f32">

А при следующей:

<div class="banner_c91e4">

Селектор .banner_a8f32 ищет элемент с классом banner_a8f32. После изменения класса он больше не найдёт нужный блок.

Иногда достаточно подобрать более устойчивый CSS-селектор. Но бывают ситуации, когда для точного поиска необходимо учитывать дополнительные признаки: текстовое содержимое, количество атрибутов, положение относительно других элементов или сочетание нескольких условий.

Именно для таких случаев в BlockIt предусмотрены дополнительные возможности.

Что такое правило BlockIt

Прежде чем перейти к способам создания правил, стоит разобраться с терминологией.

В широком смысле правило BlockIt — это описание того, как найти элементы страницы, которые необходимо заблокировать.

Для поиска можно использовать:

CSS-селектор — стандартный синтаксис для поиска элементов DOM.
XPath — язык выражений для поиска элементов в структуре документа.
Синтаксис BlockIt — собственный синтаксис расширения, дополняющий возможности CSS-селекторов.

Таким образом, даже обычный CSS-селектор, добавленный в расширение, становится правилом блокировки BlockIt.

Однако в интерфейсе расширения термин «Правило BlockIt» используется и в более узком смысле — для обозначения выражения, написанного с использованием собственного синтаксиса BlockIt, в отличие от обычного CSS-селектора.

Например, после создания правила можно увидеть пометку «CSS-селектор» или «Правило BlockIt». В этом случае названия указывают именно на используемый синтаксис.

Несколько способов создать правило

Я хотел, чтобы BlockIt подходил как для простых задач, так и для ситуаций, когда требуется подробный контроль над поиском элементов.

Поэтому в расширении предусмотрено несколько способов создания правил.

1. CSS-селектор

Самый простой вариант — выбрать элемент в Chrome DevTools, скопировать его CSS-селектор и вставить в BlockIt.

Но использовать DevTools необязательно: CSS-селектор можно написать вручную или отредактировать уже существующий.

Например:

div.notice[data-type="promo"]

Этот селектор найдёт элементы div, у которых есть класс notice и атрибут data-type со значением promo.

Расширение показывает количество найденных совпадений. Это помогает проверить, не затрагивает ли правило лишние элементы.

Для найденных элементов можно выбрать одно из двух действий:

Удалить — полностью убрать элемент из DOM, обычно освободив занимаемое им место.
Скрыть — сделать элемент невидимым, сохранив занимаемое им место на странице.

Второй вариант полезен, если после удаления элемента нарушается вёрстка.

2. XPath

BlockIt также поддерживает XPath-выражения.

Например:

//div[@data-type='promo']

Это выражение ищет элементы div, у которых атрибут data-type имеет значение promo, независимо от их расположения в документе.

XPath предоставляет дополнительные способы поиска элементов и навигации по DOM.

Однако сам по себе XPath не гарантирует устойчивости. Если выражение опирается на изменяющиеся атрибуты или положение элементов, оно тоже может перестать работать.

3. Быстрое правило из HTML

Один из наиболее удобных способов создания правил — «Быстрое правило».

Вместо готового селектора достаточно скопировать HTML нужного элемента из Chrome DevTools и вставить его в соответствующее поле BlockIt.

Расширение разбирает HTML и позволяет выбрать, какие признаки следует использовать при поиске.

Например, исходный элемент выглядит так:

<div id="cmpbox" class="cmpbox_a8f32" role="dialog">

Если класс cmpbox_a8f32 генерируется динамически, его можно исключить, оставив только атрибуты id="cmpbox" и role="dialog".

После этого достаточно нажать кнопку «Добавить правило».

Таким образом, пользователь самостоятельно определяет, какие атрибуты и классы учитывать, но ему не нужно писать селектор вручную.

Конструктор правила

Для более сложных случаев в BlockIt предусмотрен конструктор правила.

Он позволяет описывать условия поиска элементов через интерфейс, не требуя знания CSS, XPath или собственного синтаксиса BlockIt.

В конструкторе можно учитывать не только признаки самого элемента, но и его окружение.

Например:

HTML-тег, классы и атрибуты;
текстовое содержимое, включая поиск по части текста и регулярным выражениям;
количество классов и атрибутов;
положение элемента среди соседних элементов;
признаки родителей, предков, потомков и сиблингов;
расстояние до сиблинга и отсутствие определённых связанных элементов.

Условия можно комбинировать.

Допустим, на странице несколько элементов с одинаковыми классами, но нужный находится внутри контейнера с определённым атрибутом. Вместо того чтобы полагаться на порядковый номер элемента, можно использовать признаки его окружения.

Или, если классы постоянно меняются, попробовать найти элемент по тексту и другим более устойчивым характеристикам.

Конструктор показывает словесное описание сформированного правила. Это помогает контролировать, какие именно признаки участвуют в поиске, даже если пользователь не знаком с синтаксисом селекторов.

Проверка после обновления страницы

Найти нужный элемент один раз — ещё не значит создать надёжное правило.

На динамических сайтах важно убедиться, что оно продолжает работать при последующих загрузках.

Поэтому в конструкторе правила предусмотрена проверка после обновления страницы.

Она позволяет сравнить количество найденных элементов до и после перезагрузки.

Если совпадения исчезли или их количество изменилось, это может указывать на нестабильность выбранных условий.

Можно скорректировать правило и повторить проверку.

Разумеется, совпадение количества элементов ещё не гарантирует, что правило всегда будет находить именно то, что нужно. Но такая проверка помогает обнаружить некоторые проблемы ещё на этапе создания правила.

Расширенный синтаксис BlockIt

Не все условия, доступные в конструкторе, можно выразить обычным CSS-селектором.

Например, стандартный CSS не предусматривает поиск по произвольному текстовому содержимому или проверку количества атрибутов элемента.

Для таких случаев я разработал собственный синтаксис BlockIt, расширяющий возможности CSS-селекторов.

Например, можно искать элементы по собственному тексту, не учитывая текст вложенных элементов, проверять количество классов и атрибутов или задавать дополнительные условия для окружающих элементов.

Если выбранные в конструкторе условия можно выразить стандартным CSS, результатом будет обычный CSS-селектор.

Если требуются дополнительные возможности, конструктор сформирует «Правило BlockIt» — здесь этот термин используется в узком смысле, то есть обозначает выражение с использованием расширенного синтаксиса.

В обоих случаях пользователь получает готовое правило для поиска и блокировки элементов.

При этом изучать синтаксис BlockIt необязательно: сложные условия можно составлять непосредственно в конструкторе.

А для тех, кто предпочитает работать с выражениями вручную, доступна документация синтаксиса BlockIt.

Когда обычный инструмент блокировки элементов не справляется

Представим ситуацию: на сайте появился раздражающий блок, который не блокируется стандартными фильтрами установленного блокировщика рекламы.

Пользователь решает заблокировать его вручную с помощью встроенного инструмента выбора элементов. Он выделяет нужный блок, создаёт правило — и элемент исчезает.

Но после обновления страницы он появляется снова.

Причина может заключаться в том, что автоматически сформированный селектор опирался на динамический класс или изменяющуюся структуру DOM.

В такой ситуации BlockIt предлагает несколько вариантов решения.

Можно самостоятельно подобрать более устойчивый CSS-селектор, воспользоваться XPath или составить сложное правило с дополнительными условиями через конструктор.

Например, отказаться от динамического класса и учитывать текст элемента, его атрибуты или признаки окружающих контейнеров.

После этого можно проверить работу правила в конструкторе при повторной загрузке страницы.

Это позволяет справляться с некоторыми сложными элементами, для которых автоматически предложенный селектор оказался недостаточно надёжным.

Конечно, подобные задачи можно решать и другими инструментами. В частности, uBlock Origin поддерживает расширенные косметические фильтры, позволяющие описывать сложные условия поиска.

Особенность BlockIt — в сочетании нескольких способов создания правил, подробного контроля над условиями поиска и инструментов, позволяющих работать со сложными условиями без изучения специального синтаксиса.

При этом расширение не обещает автоматически находить идеальные признаки для любого элемента.

Надёжность правила зависит от особенностей конкретной страницы и от того, насколько удачно выбраны условия поиска. BlockIt предоставляет инструменты для решения этой задачи, но окончательный выбор остаётся за пользователем.

Работа с iframe и Shadow DOM

Некоторые элементы страницы находятся не в основном DOM-документе.

Например, содержимое может размещаться внутри iframe или использовать Shadow DOM.

Это создаёт дополнительные сложности при поиске и блокировке элементов.

BlockIt поддерживает применение правил внутри iframe и Shadow DOM, хотя для разных способов поиска существуют технические ограничения.

В частности, XPath не может пересекать границу Shadow DOM. Для таких случаев можно использовать правила на основе CSS или расширенного синтаксиса BlockIt.

Кроме того, собственный синтаксис BlockIt предусматривает специальные условия, связанные с iframe и Shadow DOM.

Это расширяет возможности поиска элементов в сложных структурах веб-страниц.

Как BlockIt связан со StableHTMLFinder

В предыдущей статье о StableHTMLFinder я рассказывал о проблеме нестабильных CSS-селекторов и о том, как анализировать изменения DOM между загрузками страницы.

StableHTMLFinder и BlockIt решают разные, но связанные задачи.

StableHTMLFinder помогает определить, какие элементы и признаки сохраняются при повторных загрузках страницы.

BlockIt позволяет использовать выбранные признаки для поиска и блокировки нежелательных элементов.

Например, если классы нужного блока постоянно меняются, можно сначала исследовать страницу в StableHTMLFinder, найти устойчивые признаки самого элемента или его окружения, а затем использовать их для создания правила в BlockIt.

StableHTMLFinder также может формировать CSS-селекторы и правила с использованием синтаксиса BlockIt, которые можно скопировать в расширение для блокировки.

Но использовать оба инструмента вместе необязательно: BlockIt работает самостоятельно.

Управление правилами

После создания правила можно не только применять, но и управлять им.

BlockIt позволяет отключать правила без удаления, группирует их по сайтам и поддерживает экспорт и импорт настроек.

Это удобно, если со временем накапливается много правил для разных страниц.

Все правила хранятся локально в браузере и не отправляются на сервер.

Исходный код BlockIt открыт и доступен на GitHub под лицензией BSD-3-Clause.

Попробуйте BlockIt

BlockIt — бесплатное расширение для Chrome.

Если хотите попробовать его самостоятельно, посетите официальную страницу BlockIt, там вы найдёте ссылку для скачивания расширения из Chrome Web Store.

Для знакомства с возможностями расширения я подготовил подробную инструкцию с примерами и скриншотами. В ней рассмотрены разные способы создания правил — от простого CSS-селектора до конструктора со сложными условиями.

Если вы сталкивались с элементами, которые сложно заблокировать обычными CSS-селекторами, мне было бы интересно узнать, какие способы вы использовали для решения этой задачи.

Почему CSS-селекторы ломаются и как я создал StableHTMLFinder для анализа стабильности DOM

Pavel Borisov — Thu, 22 Oct 2026 15:34:47 +0000

Если вы когда-нибудь писали CSS-селекторы для автоматизации браузера, парсинга страниц или блокировки нежелательных элементов, то наверняка сталкивались с ситуацией: вчера селектор работал, а сегодня перестал находить нужный элемент.

Причина часто заключается не в ошибке селектора, а в самой странице. Современные сайты активно используют динамически генерируемые классы, изменяющиеся атрибуты, рекламные блоки и другие элементы, структура которых может отличаться при каждой загрузке.

Я столкнулся с этой проблемой при разработке BlockIt — расширения для Chrome, позволяющего блокировать нежелательные элементы на веб-страницах.

В какой-то момент мне понадобился инструмент, который помог бы понять, какие части DOM действительно остаются неизменными при повторных загрузках страницы.

Так появился StableHTMLFinder.

В этой статье я расскажу, почему решил его создать, что представляет собой карта стабильности DOM и как она помогает находить устойчивые признаки элементов, не углубляясь во внутреннюю реализацию алгоритмов.

Проблема: DOM постоянно меняется

Представим, что нам нужно скрыть рекламный блок на сайте.

Открываем DevTools, выбираем элемент и видим примерно такой HTML:

<div class="ad-container_x7Kp2">
    <div class="banner_9fA31">
        Рекламное объявление
    </div>
</div>

Можно написать селектор:

.ad-container_x7Kp2

Он работает. Но после обновления страницы HTML уже выглядит иначе:

<div class="ad-container_m4Rz8">
    <div class="banner_2qB76">
        Рекламное объявление
    </div>
</div>

Селектор перестаёт находить элемент.

Конечно, можно попробовать использовать частичное совпадение класса:

[class^="ad-container_"]

Но такой подход работает лишь тогда, когда изменяемые значения сохраняют предсказуемую структуру.

А если меняются не только классы, но и идентификаторы, атрибуты, количество вложенных элементов или расположение блока?

Приходится изучать окружающую структуру страницы и искать более надёжные ориентиры.

Именно здесь возникает главная проблема: как отличить действительно стабильные признаки DOM от тех, которые лишь случайно выглядят стабильными при текущей загрузке?

Почему одного снимка DOM недостаточно

Большинство привычных инструментов генерации селекторов анализируют текущее состояние страницы.

Они могут определить уникальный класс, идентификатор, построить CSS-путь или XPath.

Однако уникальность и стабильность — совершенно разные свойства.

Например:

<button id="action_583921" class="btn_8xQ2">
    Продолжить
</button>

Идентификатор action_583921 может быть уникальным на странице. Но это ничего не говорит о том, сохранится ли он после обновления.

Инструмент, который видит только один снимок DOM, не может непосредственно наблюдать изменение этого идентификатора между загрузками.

Конечно, существуют эвристики, позволяющие предположить, что определённый класс или идентификатор генерируется динамически. Но предположение не заменяет наблюдение.

Когда я начинал разрабатывать StableHTMLFinder в 2026 году, мне не удалось найти инструмент, который автоматически собирал бы несколько снимков одной страницы и на их основе строил наглядную карту устойчивых элементов и их признаков.

При этом я не хотел создавать ещё один генератор селекторов.

Первоначальная идея была гораздо проще: убрать из DOM весь нестабильный информационный шум и посмотреть, что останется.

Карта стабильности DOM

StableHTMLFinder — бесплатное расширение для Chrome, которое анализирует несколько последовательных загрузок веб-страницы и строит на их основе карту стабильности.

По своей структуре она напоминает DOM-дерево, но имеет принципиальное отличие: в ней отображаются только те элементы и признаки, стабильность которых удалось установить.

Допустим, при нескольких загрузках страницы встречается один и тот же элемент:

Первая загрузка:

<section class="content_a72" data-session="1842">
    <h2 class="section-title">Новости</h2>
</section>

Вторая загрузка:

<section class="content_b91" data-session="7501">
    <h2 class="section-title">Новости</h2>
</section>

Третья загрузка:

<section class="content_c38" data-session="3926">
    <h2 class="section-title">Новости</h2>
</section>

В этом упрощённом примере можно заметить:

Тег section сохраняется.
Атрибут class присутствует, но его значение меняется.
Атрибут data-session присутствует, но его значение тоже меняется.
Дочерний элемент h2 и его класс остаются неизменными.

Если сопоставление элементов между загрузками достаточно надёжно, карта может представить эту структуру примерно так:

<section class data-session>
    <h2 class="section-title">
        Новости
    </h2>
</section>

Это схематический пример, а не точное представление интерфейса StableHTMLFinder.

Обратите внимание: имена атрибутов class и data-session остались, а их нестабильные значения исчезли.

Таким образом, карта позволяет различать несколько ситуаций:

Стабилен элемент вместе с атрибутами и их значениями.
Стабилен элемент и наличие определённых атрибутов, но не их значения.
Удалось установить стабильность самого элемента, но его атрибуты не дают надёжных ориентиров.

Смысл такого представления — не показать пользователю как можно больше HTML, а оставить только информацию, которая потенциально полезна для построения устойчивого селектора.

Вместо того чтобы разбираться в десятках случайных классов, можно сосредоточиться на признаках, которые действительно сохраняются между загрузками.

На скриншоте показан фрагмент карты стабильности DOM, построенной расширением StableHTMLFinder. Зелёным цветом выделены стабильные элементы и их атрибуты, сохраняющиеся при повторных загрузках страницы. Один из элементов, ссылка <a>, раскрыт для просмотра дополнительной информации. Для него StableHTMLFinder сформировал CSS-селектор и правило для расширения BlockIt, которые можно скопировать одним нажатием. Древовидная структура карты позволяет исследовать вложенные элементы и их атрибуты, а также переходить от анализа стабильности DOM к практическому использованию найденных селекторов.

Полностью и относительно стабильные элементы

Не все элементы удаётся сопоставить между загрузками с одинаковой уверенностью.

Поэтому StableHTMLFinder различает полностью и относительно стабильные элементы.

Полностью стабильные элементы — наиболее надёжные участки карты. Их собственные признаки, а также соответствующие признаки родительских и непосредственно дочерних элементов совпадают между наблюдениями.

Такие элементы служат хорошими ориентирами при анализе структуры страницы.

Относительно стабильные элементы — элементы, для которых имеются достаточные основания считать, что в разных загрузках речь идёт об одном и том же DOM-узле, хотя часть признаков или окружающей структуры изменяется.

На карте они выделяются более светлым цветом.

Это важное различие: StableHTMLFinder не утверждает, что всё на странице либо абсолютно неизменно, либо полностью непригодно для анализа.

В реальных веб-приложениях ситуация гораздо сложнее.

Элемент может сохранять своё назначение, но менять классы. Его родитель может получать новые атрибуты. Между двумя знакомыми элементами могут появляться дополнительные контейнеры.

Поэтому полезно видеть не только абсолютно стабильные участки, но и те, для которых удалось установить относительную стабильность.

Островки стабильности внутри динамического DOM

Одна из наиболее интересных особенностей StableHTMLFinder — способность отображать островки стабильности.

Представим, что между загрузками страницы меняется целая цепочка вложенных контейнеров.

В одном случае нужный элемент находится внутри двух промежуточных блоков, в другом — внутри четырёх. Их классы и атрибуты также могут различаться.

Но где-то внутри этой нестабильной структуры сохраняется элемент с узнаваемыми признаками.

Было бы неправильно полностью отбрасывать его только потому, что его предки нестабильны.

StableHTMLFinder сохраняет такие стабильные участки на карте, а разделяющую их нестабильную структуру обозначает специальным серым элементом <...>.

Они выглядят как элементы дерева, но фактически обозначают изменяющуюся структуру произвольной вложенности. Этот элемент может представлять произвольное количество нестабильных уровней вложенности, а не только один пропущенный узел.

В результате пользователь видит, что между стабильными участками страницы существует нестабильная область, но при этом не теряет возможность исследовать расположенные внутри неё элементы.

Это особенно полезно на страницах, где JavaScript динамически перестраивает отдельные части интерфейса.

Поиск элементов на карте стабильности

Допустим, вы обнаружили на сайте элемент, который хотите заблокировать.

Открыли DevTools, нашли соответствующий HTML, но его классы и идентификаторы выглядят случайными.

Вместо ручного исследования множества родительских и дочерних узлов можно воспользоваться поиском StableHTMLFinder.

Он позволяет искать элементы на карте несколькими способами, в том числе:

Вставить HTML-элемент, скопированный из DevTools.
Указать селектор для поиска нужного элемента.

Если элемент присутствует на карте стабильности, можно перейти к его карточке и изучить доступные устойчивые признаки.

Это позволяет быстро перейти от исходного DOM, заполненного динамическими значениями, к его очищенному представлению.

Особенно удобно, когда проблемный элемент сам по себе не содержит подходящих признаков, но рядом с ним находятся более стабильные элементы.

Как повысить точность поиска

StableHTMLFinder выполняет поиск преимущественно по последнему снимку DOM, полученному во время анализа страницы.

Если после завершения анализа страница не перезагружалась, а нужный элемент ещё не изменился под воздействием JavaScript, его можно скопировать из DevTools и вставить в поиск. В этом случае расширение точно найдёт соответствующий элемент на карте стабильности, даже если все его атрибуты и их значения оказались нестабильными и на карте сохранился только тег элемента.

Если же вы скопировали элемент, который был уже изменён после последнего снимка DOM, поиск всё ещё может оказаться успешным. StableHTMLFinder попытается сопоставить его с элементами карты по сохранившимся признакам, однако уверенность в результате будет ниже.

Автоматическая генерация селекторов

Хотя StableHTMLFinder изначально задумывался как инструмент визуального анализа DOM, впоследствии я добавил автоматическую генерацию селекторов.

Это оказалось естественным продолжением основной идеи.

Если инструмент уже определил стабильные признаки элемента и его окружения, почему бы не попробовать автоматически построить селектор на их основе?

В карточке элемента можно получить предложенный селектор и скопировать его.

Рядом отображается текстовое объяснение, позволяющее понять, на каких признаках он основан.

Это важно, потому что селектор не должен оставаться для пользователя непонятной строкой.

Однако здесь есть важное ограничение.

В особо сложных случаях StableHTMLFinder может оказаться не в состоянии сформировать уникальный селектор для определённого элемента.

Хотя расширение обычно успешно формирует уникальные селекторы, у некоторых элементов отсутствует уникальная комбинация стабильных признаков в их ближнем окружении DOM. В таких редких случаях StableHTMLFinder явно сообщает, что сформировать уникальный селектор не удалось.

В таких случаях сама карта стабильности всё равно может быть полезна: она предоставляет информацию для самостоятельного поиска решения.

Именно поэтому я рассматриваю генерацию селекторов как вспомогательную возможность, а не как основное назначение расширения.

Как StableHTMLFinder связан с BlockIt

StableHTMLFinder появился в процессе работы над другим моим проектом — BlockIt.

BlockIt — расширение Chrome для блокировки нежелательных элементов на веб-страницах.

Оно позволяет создавать правила с использованием CSS, XPath и дополнительных условий, а также применять более сложные способы поиска элементов.

Но даже достаточно выразительный синтаксис не решает главную проблему: если правило основано на нестабильных признаках, оно может перестать работать после очередного обновления страницы.

StableHTMLFinder помогает найти более надёжные ориентиры для таких правил.

При этом два расширения решают разные задачи:

StableHTMLFinder анализирует страницу, показывает карту стабильности и помогает создавать селекторы. Само расширение ничего не блокирует.

BlockIt использует правила для поиска и блокировки нежелательных элементов на страницах.

StableHTMLFinder также может предлагать специальные правила, предназначенные для использования в BlockIt.

Таким образом, одно расширение помогает исследовать DOM и подготовить правило, а другое — применить его на практике.

Подробнее о BlockIt я расскажу в отдельной статье.

Может ли StableHTMLFinder быть полезен за пределами блокировки рекламы?

Хотя проект возник из задачи блокировки нежелательных элементов, сама проблема нестабильных DOM-локаторов встречается и в других областях.

Например, при разработке браузерной автоматизации и UI-тестов.

Если тест использует динамический класс, он может перестать работать после изменения страницы, даже когда нужная кнопка или форма по-прежнему существует.

Карта стабильности потенциально может помочь разработчику определить более надёжные ориентиры.

Аналогичная задача иногда возникает при создании скриптов, взаимодействующих с веб-страницами, и инструментов извлечения данных.

Однако StableHTMLFinder не является универсальным решением для этих сценариев. Его возможности зависят от структуры конкретного сайта и наличия признаков, которые сохраняются между загрузками.

Кроме того, стабильность, установленная на основании нескольких наблюдений, не означает, что элемент никогда не изменится в будущем.

Карта отражает результаты проведённого анализа, а не даёт абсолютную гарантию.

Почему я считаю этот подход полезным

При разработке StableHTMLFinder я хотел изменить сам процесс работы с DOM.

Обычно разработчик открывает DevTools, видит огромное дерево элементов и пытается самостоятельно определить, какие признаки пригодны для селектора.

Но большая часть этой информации может оказаться бесполезной: случайные классы, временные идентификаторы, динамические атрибуты, постоянно перестраивающиеся контейнеры.

StableHTMLFinder предлагает другой подход:

Сначала определить, что остаётся стабильным между загрузками страницы, и только потом решать, как использовать эти признаки.

Это не устраняет все сложности динамического DOM и не делает селекторы неуязвимыми к изменениям сайта.

Но позволяет сосредоточиться на более надёжной информации и избежать значительной части ручной работы.

И, пожалуй, это лучше всего описывает первоначальную идею проекта: не столько автоматически написать селектор за пользователя, сколько дать ему возможность увидеть страницу без нестабильного информационного шума.

Попробуйте StableHTMLFinder

StableHTMLFinder — бесплатное расширение для Chrome.

Если хотите попробовать его в работе, посетите официальную страницу проекта StableHTMLFinder, где вы найдёте ссылку для установки расширения из Chrome Web Store.

Если вы работаете с динамическими веб-страницами, мне было бы интересно узнать, с какими проблемами стабильности селекторов вы сталкивались и как подходили к их решению.

Why CSS Selectors Break — and How I Built StableHTMLFinder to Analyze DOM Stability

Pavel Borisov — Tue, 20 Oct 2026 12:00:00 +0000

If you've ever written CSS selectors for browser automation, web scraping, or blocking unwanted elements, you've probably encountered this situation: a selector works perfectly today, but tomorrow it can no longer find the element you need.

Often, the problem isn't the selector itself. It's the page.

Modern websites frequently use dynamically generated classes, changing attributes, advertising elements, and JavaScript-driven interfaces whose DOM structure can differ between page loads.

I encountered this problem while developing BlockIt, a Chrome extension for blocking unwanted elements on web pages.

At some point, I needed a tool that would help me understand which parts of the DOM actually remain unchanged across repeated page loads.

That's how StableHTMLFinder was born.

In this article, I'll explain why I created it, what a DOM stability map is, and how it helps identify reliable element characteristics — without going into the internal implementation of its algorithms.

The Problem: The DOM Keeps Changing

Imagine you want to hide an advertising block on a website.

You open DevTools, inspect the element, and see something like this:

<div class="ad-container_x7Kp2">
    <div class="banner_9fA31">
        Advertisement
    </div>
</div>

You could write a selector:

.ad-container_x7Kp2

It works. But after refreshing the page, the HTML looks different:

<div class="ad-container_m4Rz8">
    <div class="banner_2qB76">
        Advertisement
    </div>
</div>

Your selector no longer matches the element.

Of course, you could try matching part of the class name:

[class^="ad-container_"]

But this approach only works when dynamically generated values follow a predictable pattern.

What if not only classes but also IDs, attributes, nesting levels, or element positions change?

You have to examine the surrounding DOM structure and look for more reliable reference points.

This leads to the central question:

How can we distinguish genuinely stable DOM characteristics from those that merely happen to look stable in the current page load?

Why a Single DOM Snapshot Isn't Enough

Many conventional selector-generation tools analyze the current state of a page.

They can identify a unique class or ID, construct a CSS path, or generate an XPath expression.

But uniqueness and stability are two very different things.

Consider this example:

<button id="action_583921" class="btn_8xQ2">
    Continue
</button>

The ID action_583921 might be unique on the page. But that tells us nothing about whether it will remain the same after a refresh.

A tool that examines only one DOM snapshot cannot directly observe how that ID changes between page loads.

Of course, heuristics can help identify classes or IDs that appear to be dynamically generated. But an educated guess is not the same as observation.

When I started developing StableHTMLFinder in 2026, I couldn't find a tool that automatically collected multiple snapshots of the same page and used them to build a visual map of stable elements and their characteristics.

And I wasn't trying to build another selector generator.

My original idea was much simpler: remove all the unstable noise from the DOM and see what remains.

Introducing the DOM Stability Map

StableHTMLFinder is a free Chrome extension that analyzes multiple consecutive page loads and builds a stability map from the collected DOM snapshots.

Its structure resembles a DOM tree, but with one fundamental difference: it displays only elements and characteristics whose stability has been established during the analysis.

Suppose the same element appears across several page loads.

First load:

<section class="content_a72" data-session="1842">
    <h2 class="section-title">News</h2>
</section>

Second load:

<section class="content_b91" data-session="7501">
    <h2 class="section-title">News</h2>
</section>

Third load:

<section class="content_c38" data-session="3926">
    <h2 class="section-title">News</h2>
</section>

In this simplified example, we can observe that:

The section tag remains unchanged.
The class attribute is always present, but its value changes.
The data-session attribute is always present, but its value also changes.
The child h2 element and its class remain unchanged.

If the elements can be matched reliably across page loads, the stability map might represent the structure approximately like this:

<section class data-session>
    <h2 class="section-title">
        News
    </h2>
</section>

This is a schematic illustration, not an exact representation of the StableHTMLFinder interface.

Notice that the attribute names class and data-session remain, while their unstable values disappear.

The stability map can therefore distinguish between several situations:

An element, its attributes, and their values are stable.
An element and certain attribute names are stable, but their values are not.
The element itself can be identified across page loads, but its attributes provide no reliable reference points.

The purpose of this representation isn't to show as much HTML as possible.

It's to retain only information that may be useful for constructing a reliable selector.

Instead of examining dozens of random-looking classes, you can focus on characteristics that actually remain consistent across page loads.

Here's what a section of the stability map looks like in practice. This example shows a fully stable part of a web page, where elements and their attributes remain consistent across multiple page loads. The tree-like structure makes it easy to explore these elements and their relationships without the distraction of unstable DOM characteristics.

Fully Stable and Relatively Stable Elements

Not every element can be matched across page loads with the same level of confidence.

That's why StableHTMLFinder distinguishes between fully stable and relatively stable elements.

Fully stable elements are the most reliable parts of the stability map. Their own characteristics, along with those of their parents and immediate children, match exactly across the analyzed snapshots.

These elements provide particularly useful reference points when examining the page structure.

Relatively stable elements are elements for which there is sufficient evidence that they represent the same DOM element across different page loads, even though some characteristics or parts of the surrounding structure may change.

They are displayed in a lighter color on the stability map.

This is an important distinction: StableHTMLFinder doesn't assume that everything on a page must be either completely stable or entirely unsuitable for analysis.

In real-world web applications, things are much more complicated.

An element may retain its purpose while its classes change. Its parent may receive new attributes. Additional containers may appear between otherwise familiar elements.

Rather than discarding everything that isn't perfectly stable, StableHTMLFinder preserves elements whose identity can still be established with reasonable confidence.

Islands of Stability Inside a Dynamic DOM

One of the more interesting features of StableHTMLFinder is its ability to display islands of stability.

Imagine that an entire chain of nested containers changes between page loads.

During one load, the element you're interested in is nested inside two intermediate containers. During another, it might be nested inside four. Their classes and attributes may also be different.

But somewhere inside this unstable structure, an element with recognizable characteristics remains.

It would be a mistake to discard that element simply because its ancestors are unstable.

StableHTMLFinder can preserve such an element on the stability map while representing the unstable intermediate levels using special gray placeholders.

These placeholders resemble elements in the tree, but they actually represent unstable structures with potentially varying nesting depths.

As a result, you can see that an unstable region exists between stable parts of the page without losing the ability to examine the elements inside it.

This can be particularly useful on websites where JavaScript dynamically rebuilds parts of the interface.

Finding Elements on the Stability Map

Suppose you've found an element on a website that you want to block.

You open DevTools and inspect its HTML, but the classes and IDs look randomly generated.

Instead of manually examining numerous parent and child elements, you can use StableHTMLFinder's search feature.

The search supports several approaches, including:

Pasting an HTML element copied from DevTools.
Entering a selector to locate the corresponding element.

If the element exists on the stability map, you can navigate to its card and examine the available stable characteristics.

This provides a convenient way to move from the original DOM, filled with dynamically changing values, to a cleaner representation of the same page.

It's particularly helpful when the target element itself has no reliable attributes, but more stable elements exist nearby.

How to Improve Search Accuracy

StableHTMLFinder performs its search primarily against the last DOM snapshot collected during the analysis.

If you haven't reloaded the page since the analysis finished, and the target element hasn't changed due to JavaScript activity, you can copy it from DevTools and paste it into the search field.

In this case, the extension will accurately locate the corresponding element on the stability map, even if all its attributes and their values turned out to be unstable and only the element's tag remains on the map.

If, however, you copied an element that had already changed since the last DOM snapshot, the search may still succeed. StableHTMLFinder will attempt to match it using the characteristics that remain recognizable, but with a lower level of confidence.

Automatic Selector Generation

Although StableHTMLFinder was originally designed as a visual DOM analysis tool, I later added automatic selector generation.

It seemed like a natural extension of the original idea.

If the tool has already identified stable characteristics of an element and its surroundings, why not try generating a selector from them?

From an element's card, you can obtain a suggested selector and copy it.

A human-readable explanation is displayed alongside the selector, describing which characteristics were used to construct it.

I consider this important because a selector shouldn't be an incomprehensible string that users have to trust blindly.

However, there's an important limitation.

In particularly complex cases, StableHTMLFinder may be unable to generate a unique selector for a given element.

Although the extension can usually generate a unique selector, some elements lack a unique combination of stable characteristics within their nearby DOM structure. In these rare cases, StableHTMLFinder clearly indicates that a unique selector could not be generated.

Some pages are structured in ways that simply don't provide enough stable characteristics.

In those cases, the stability map can still be valuable because it gives you the information needed to investigate the problem and develop your own solution.

That's why I see automatic selector generation as a convenience feature rather than the extension's primary purpose.

How StableHTMLFinder Connects to BlockIt

StableHTMLFinder originated while I was working on another project of mine: BlockIt.

BlockIt is a Chrome extension for blocking unwanted elements on web pages.

It supports rules based on CSS, XPath, and additional conditions, along with more advanced methods of locating elements.

But even a powerful rule syntax can't solve the fundamental problem: if a rule relies on unstable characteristics, it may stop working after the next page load.

StableHTMLFinder helps identify more reliable reference points for those rules.

The two extensions serve different purposes:

StableHTMLFinder analyzes a page, displays its stability map, and helps create selectors. It doesn't block anything itself.

BlockIt uses rules to locate and block unwanted elements on web pages.

StableHTMLFinder can also suggest special rules designed for use with BlockIt.

In other words, one extension helps you investigate the DOM and prepare a rule, while the other applies that rule in practice.

I'll cover BlockIt and its capabilities in a separate article.

Can StableHTMLFinder Be Useful Beyond Ad Blocking?

Although the project grew out of the need to block unwanted elements, unstable DOM locators are a problem in other areas as well.

One example is browser automation and UI testing.

If a test relies on a dynamically generated class, it may fail after a page update even though the button or form it's supposed to interact with still exists.

A stability map could potentially help developers identify more reliable reference points.

Similar challenges sometimes arise when writing browser scripts or extracting data from websites.

However, StableHTMLFinder isn't a universal solution for these scenarios. Its usefulness depends on the structure of the particular website and whether sufficiently stable characteristics can be identified.

There's also an important distinction between observed stability and guaranteed future stability.

Just because an element remained unchanged across several page loads doesn't mean it will never change.

The stability map reflects the results of the analysis, not an absolute guarantee.

Why I Think This Approach Matters

When developing StableHTMLFinder, I wanted to change the way I worked with the DOM.

Normally, a developer opens DevTools, sees an enormous tree of elements, and tries to figure out which characteristics are suitable for a selector.

But much of that information may be useless: random classes, temporary IDs, dynamic attributes, and constantly changing containers.

StableHTMLFinder takes a different approach:

First, identify what remains stable across page loads. Then decide how to use those characteristics.

This doesn't eliminate every challenge associated with dynamic DOM structures, and it doesn't make selectors immune to future website changes.

But it allows you to focus on more reliable information and reduce the amount of manual investigation required.

And perhaps that best captures the original idea behind the project: not necessarily to write a selector for you, but to let you see a web page without the noise of constantly changing DOM characteristics.

Try StableHTMLFinder

StableHTMLFinder is a free Chrome extension.

If you'd like to try it yourself, visit the official StableHTMLFinder project page, where you'll find a link to install the extension from the Chrome Web Store.

If you work with dynamic web pages, I'd be interested to hear what challenges you've encountered with selector stability and how you've approached solving them.