Source: https://bscan.info/de/blog/detect-devtools Language: de Inspect Element sieht eine Seite nicht, aber ob die DevTools offen sind, schon. Teste die Checks live und lerne, wie du Einfrieren und Umleitungen stoppst. # Erkennt eine Website Inspect Element und offene DevTools? Veröffentlicht 18\. Oktober 2026 ![Fraglich](https://bscan.info/QuestionIcon.svg) Öffne die DevTools (F12) und sieh zu, wie diese Seite es merkt Alles läuft in deinem Browser, nichts wird gesendet. Öffne die DevTools, ändere den Preis, drück den Button. Letzte Events, die die Seite protokolliert hat - noch nichts Was diese Seite mitbekommen kann - Angedocktes Panel (Fenstergrößen-Differenz) wartet dock die DevTools an der Seite oder unten an - Konsolenkosten (Zeitmessung) wartet öffne die DevTools (F12), beliebiges Panel, beliebige Position - debugger-Zeitmessung wartet öffne die DevTools und drück dann den Button unten - Änderungen an der Seite wartet untersuche den Preis unten und ändere seinen Text - Kürzel und Rechtsklick wartet drück F12 oder klick mit der rechten Maustaste auf diese Seite Preis: $49.00 Rechtsklick auf den Preis, Untersuchen wählen und den Text ändern. Der Button führt ein debugger-Statement aus: Bei offenen DevTools friert die Seite ein, bis du die Skriptausführung fortsetzt (F8). Was kein Event meldet - Welches Element du mit Untersuchen ausgewählt hast unsichtbar - Welches Panel du gerade liest (Netzwerk, Quellen, …) unsichtbar - Dass ein view-source-Tab geöffnet wurde unsichtbar Wird nur im Arbeitsspeicher gezählt und ist weg, sobald du den Tab schließt. Das Widget beobachtet nur: Es blockiert kein Kürzel und versteckt dir nichts. Du drückst F12 und die Seite wird weiß. Oder sie wirft dich auf die Startseite, friert hinter dem Banner „In Debugger pausiert“ ein oder gibt „developer tools detected“ aus und lädt nicht weiter. So oder so hat die Seite etwas gemerkt, und kein Event hat es ihr gesagt. Die Skripte einer Seite bekommen kein Signal, wenn du die DevTools öffnest, ein Element auswählst oder ein Panel liest. Was sie können: bemerken, was offene DevTools mit der Seite anstellen. Das Widget auf dieser Seite führt diese Checks in deinem eigenen Browser aus. Öffne also jetzt die DevTools und sieh zu, wie es reagiert. **Die Kurzfassung:** Kein Seitenskript erfährt, dass du etwas untersucht hast. Skripte schließen aus Nebeneffekten, dass die DevTools offen sind: Ein angedocktes Panel verkleinert die Seite, Logging wird langsamer, ein `debugger`\-Statement hält die Seite an, während die Uhr weiterläuft. Gegen zwei dieser drei Checks gibt es einen einfachen Ausweg (Panel abdocken, Breakpoints deaktivieren). Gegen die Konsolen-Zeitmessung nicht, und sie schlägt auch bei Puppeteer an. Nichts davon identifiziert eine Person, und die Checks im Widget laufen komplett in deinem Browser. ## Sieht eine Website, wenn du Inspect Element benutzt? Nicht über ihre Skripte. Browser feuern kein Event „DevTools geöffnet“, und ein ausgewähltes Element oder ein gelesenes Panel verrät der Seite nichts. Der Server sieht weiterhin ganz normale Anfragen. „Seitenquelltext anzeigen“ ist eine gewöhnliche Anfrage nach der Seite oder ein Lesezugriff auf deinen Cache, und Chrome lädt die Source Maps einer Website, sobald die DevTools aufgehen. Liefert ein Server sie aus, kann er das also protokollieren. Welches Element du ausgewählt oder welches Panel du gelesen hast, erfährt er nie. Eine Seite in Inspect Element zu bearbeiten, ändert für niemand sonst etwas. Du änderst die Kopie in deinem Tab, die Kopie des Servers bleibt unberührt, und ein Reload bringt das Original zurück. Dass eines ihrer Elemente verändert wurde, kann die Seite allerdings bemerken, denn ein [`MutationObserver`](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver) meldet solche Änderungen als ganz normale DOM-Änderungen. Ich habe das in Chrome für Text- und Attributänderungen bestätigt, und aus dem Eintrag geht nicht hervor, wer die Änderung gemacht hat. Probier es am Preis im Widget: Rechtsklick, Untersuchen, Text ändern. Das Diagramm zeigt, wo die Änderung landet. Wessen Kopie hast du bearbeitet? Der Server der Website $49.00 was der Shop berechnet Dein Browser, dieser Tab $49.00 eine Kopie der Seite im Arbeitsspeicher Der eigene MutationObserver der Seite noch nichts geändert Eine Simulation dessen, was eine Änderung im Panel „Elemente“ bewirkt. Sie ändert die Kopie in deinem Tab. Die Seite kann bemerken, dass sich ihre eigenen Elemente geändert haben, aber nicht, dass die DevTools es waren, und der Server berechnet weiterhin $49.00. Ein Reload wirft die Änderung weg. ## Wie eine Seite erkennt, dass die DevTools offen sind Drei der Tricks funktionieren nach demselben Prinzip. Die Seite kann nicht fragen „Sind die DevTools offen?“, also baut sie eine Messung auf und wartet auf einen Nebeneffekt. Die Idee kennst du von der [Adblocker-Erkennung](https://bscan.info/de/blog/adblock-detection): Die Seite sieht das Tool nicht, also misst sie, was das Tool verändert. **Die Fenstergrößen-Differenz.** Dockst du die DevTools an der Seite oder unten an, nehmen sie der Seite Platz weg, und `window.outerWidth - window.innerWidth` (oder das Höhen-Pendant) springt. Skripte werten eine Differenz von etwa 160 bis 170 Pixeln als Treffer. Auf meinem Windows-11-Rechner sprang die Breitendifferenz beim Andocken rechts von 14 auf 569 Pixel, und nach dem Abdocken lag sie wieder bei 14. Fälschlich schlägt der Check an, wenn du die Seite zoomst oder eine Seitenleiste öffnest. Die bekannteste Bibliothek dafür, [devtools-detect](https://github.com/sindresorhus/devtools-detect), wurde im Mai 2026 archiviert, und ihr README räumt ein, dass die Methode viele False Positives liefert. **Konsolenkosten.** Der Klassiker loggt ein Objekt mit einem Getter und wartet, ob die Konsole ihn ausliest. Viele ältere Antworten beschreiben das noch, aber im aktuellen Chrome feuert es nicht mehr: In meinem Test mit Chrome 155 unter Windows blieben ein Getter auf `Error.stack` und einer auf der `id` eines Elements bei offenen DevTools stumm. Andere Varianten, etwa ein eigenes `toString`, feuern immer, egal ob die DevTools offen sind, und sagen deshalb nichts aus. Was weiterhin auffällt, ist die Zeit. Logging ist nahezu kostenlos, bis sich ein Konsolen-Client anhängt, dann muss Chrome für jedes Objekt eine Vorschau bauen. Vierzig `console.debug`\-Aufrufe auf einem Objekt mit 40 Schlüsseln brauchten bei geschlossenen DevTools unter einer Millisekunde und bei offenen einige Millisekunden, auf meinem Rechner etwa das Zehnfache. Ob das Panel angedockt war oder in einem eigenen Fenster, machte keinen Unterschied. Derselbe Sprung zeigte sich bei einer reinen Chrome-DevTools-Protocol-Session, wie Puppeteer und Playwright sie standardmäßig öffnen. Eine Seite, die ihr eigenes Logging gegen eine Baseline misst, merkt das. Der Check unterscheidet allerdings nicht zwischen Entwickler und Skript, und genau deshalb setzt die [Bot-Erkennung](https://bscan.info/de/blog/bot-detection) ihn ein. Firefox und Safari habe ich nicht getestet. **Das `debugger`\-Statement.** Ohne DevTools tut es nichts. Bei offenen DevTools und aktiven Breakpoints hält es die Seite an, bis du die Skriptausführung fortsetzt (F8). Ein Skript liest davor und danach die Uhr, und eine Lücke von über etwa 100 ms gilt als Pause. Skripte deuten das als „jemand schaut hin“, auch wenn ein gedrosselter Tab oder ein langsamer Rechner das vortäuschen kann. Das ist auch das Banner „In Debugger pausiert“. Der Button im Widget führt es einmal aus, damit du es spürst. **Der Edit-Watcher.** Das vierte Signal ist gar kein DevTools-Check. Es ist der `MutationObserver` aus dem Abschnitt oben, gerichtet auf alles, was ein Skript schützen will, etwa einen Preis oder ein Paywall-Element. Er meldet die Änderung, nicht die DevTools. Drei Checks, zwei einfache Umgehungen Breakpoints deaktiviert - Fenstergrößen-Differenz Äußeres Fenster minus Seitenbereich erkannt - Konsolenkosten 40 Konsolenaufrufe gegen eine Baseline messen erkannt - debugger-Zeitmessung Ein debugger-Statement und eine Stoppuhr erkannt Checks, die die DevTools bemerken: **3 / 3** Kein einzelner Check erfasst jede Art, die DevTools zu öffnen. Gegen zwei gibt es einen einfachen Ausweg (Panel abdocken, Haltepunkte deaktivieren), deshalb kombinieren Erkennungsskripte mehrere Checks, und deshalb lassen sich die Konsolenkosten am schwersten vermeiden. ## Warum eine Website einfriert, umleitet oder „developer tools detected“ sagt Websites, die reagieren, nutzen nicht nur einen Trick. Christian Heilmann hat ein solches Skript in [Cracking a “Developer Tools Killer” script](https://dev.to/codepo8/cracking-a-developer-tools-killer-script-2lpl) auseinandergenommen. Es blockiert Rechtsklick sowie die Kürzel F12, Ctrl+Shift+I und Ctrl+U, lässt dann alle 100 ms eine `debugger`\-Schleife laufen und leitet die Seite um, wenn eine Pause länger als 200 ms dauert. Seine Check-Funktion steckt nicht in einer Closure, also hat er sie einfach überschrieben. Das Motiv ist meist, Kopieren und Scrapen lästiger zu machen. Geschützt wird damit nichts, denn alles, was der Server schickt, liegt schon in deinem Browser. Kopieren, Einfügen, Tabwechsel und Screenshots sind eine eigene Gruppe von Signalen, die wir in [Sieht eine Website Tabwechsel, Kopieren und Screenshots](https://bscan.info/de/blog/can-websites-see-tab-switching) behandeln. ## Kann eine Website Inspect Element oder F12 blockieren? Eine Seite kann die Key-Events für F12 und Ctrl+Shift+I sowie das Rechtsklick-Menü abbrechen, und die meisten „Blocker“-Skripte tun genau das. Das ist Kosmetik. Das Browsermenü (Weitere Tools, Entwicklertools) läuft außerhalb der Seite und lässt sich nicht aufhalten. Die letzte Zeile des Widgets protokolliert, welche dieser Events in deinem Browser die Seite erreichen. Es beobachtet nur und bricht nie etwas ab. ## DevTools-Erkennung umgehen und den Freeze stoppen Die DevTools sind eine Standardfunktion des Browsers. Wenn ein Check darauf anschlägt, ist das das Problem der Website. Wähle den Fix passend zum Check: 1. **Haltepunkte deaktivieren** im Panel „Quellen“ (Ctrl+F8, auf dem Mac Cmd+F8). Jedes `debugger`\-Statement wird zum No-op, und der Pausen-Check sieht keine Lücke. 2. **Das Panel abdocken** in ein eigenes Fenster, was die Fenstergrößen-Differenz aushebelt. 3. **Das Skript selbst behandeln**, wenn die Konsolen-Zeitmessung anschlägt. Keine Einstellung versteckt die Konsole vor einer Seite. Du kannst das Erkennungsskript überschreiben oder blockieren, wie es Heilmanns Walkthrough durch das Überschreiben der Check-Funktion tut, oder eine gespeicherte Kopie der Seite untersuchen, die keine Skripte ausführt. Greif nicht zu einer Erweiterung, die `window.outerWidth` fälscht oder `console` patcht. Ein ersetztes Built-in meldet nicht mehr `[native code]`, und das ist ein eigenes Erkennungszeichen, genauso wie [gepatchte native Funktionen](https://bscan.info/de/blog/bot-detection) bei der Bot-Erkennung. ## Ist Inspect Element illegal? Nein. Jeder große Browser liefert es mit und dokumentiert es, und es ändert nur deine lokale Kopie. Ärger beginnt erst bei dem, was du danach tust: Ein manipulierter Screenshot, der als echte Quittung, Rechnung oder echter Kontoauszug ausgegeben wird, kann je nach Land und Absicht Fälschung oder Betrug sein, egal mit welchem Tool er entstanden ist. ## Wenn du Browser in großem Stil betreibst Für Entwickler bedeutet ein Treffer eine kaputte Seite, bis sie die Breakpoints deaktivieren. Wer Browser in großem Stil betreibt, bekommt auf jeder Website, die die Kosten ihres Konsolen-Loggings misst, ein Flag, denn die Kosten verschieben sich, sobald sich ein Automatisierungskanal anhängt, nicht nur wenn ein Mensch die DevTools öffnet. Wenn du Profile mit Puppeteer oder Playwright steuerst, lass jedes Setup gegen das Widget oben laufen, ohne geöffnetes DevTools-Fenster, bevor du dich darauf verlässt. [Incogniton](https://www.incogniton.com/?utm_source=bscanInfo&utm_medium=Website&utm_campaign=DetectDevtoolsBlog)\-Profile sind echte Chromium-Builds, die Checks oben gelten für sie also genauso wie für Chrome. Ob die Konsolen-Zeitmessung ruhig bleibt, hängt davon ab, wie du das Profil ansteuerst, das musst du selbst testen. Ob eine Website Automatisierung erlaubt, bestimmen ihre eigenen Regeln, lies sie also zuerst. Probier es gleich aus: Öffne die DevTools, während das Widget zusieht, dann dock das Panel ab und deaktiviere die Breakpoints. Zwei Zeilen werden still. Die Konsolen-Zeile nicht. Der [komplette Browser-Scan](https://bscan.info/de) deckt den Rest dessen ab, was eine Seite lesen kann, vom Netzwerk bis zum Fingerprint. [Kompletten Browser-Scan starten](https://bscan.info/de) ## Weiterlesen [ ![Können Websites deinen Computernamen sehen?](https://bscan.info/computerNameCover.svg) Können Websites deinen Computernamen sehen? ](https://bscan.info/de/blog/computer-name)[ ![Können Websites deine Zwischenablage lesen? Teste beide Wege](https://bscan.info/clipboardAccessCover.svg) Können Websites deine Zwischenablage lesen? Teste beide Wege ](https://bscan.info/de/blog/can-websites-read-clipboard)[ ![Sieht eine Website Tabwechsel, Kopieren und Screenshots?](https://bscan.info/tabSwitchCover.svg) Sieht eine Website Tabwechsel, Kopieren und Screenshots? ](https://bscan.info/de/blog/can-websites-see-tab-switching) --- This is the page's server-rendered documentation. Interactive browser tests, file processing and permission prompts require the HTML page; Markdown does not contain live measurements or process files.