5 nützliche Bookmarklets für Entwickler

Ein Bookmarklet ist ein Lesezeichen, dessen URL eine einzelne JavaScript-Zeile mit dem Präfix javascript: ist. Ein Klick darauf führt diesen Code auf der aktuellen Seite aus, anstatt zu einer anderen Seite zu navigieren. Damit sind Bookmarklets der schnellste Weg ohne Installation, um eine Seite live zu bearbeiten, das Layout zu debuggen, ein maskiertes Eingabefeld aufzudecken oder eine Farbe zu ermitteln – ganz ohne Extension, ohne DevTools-Panel und ohne Build-Schritt. Dieser Artikel stellt fünf wirklich nützliche, sauber formulierte Bookmarklets vor, die in aktuellen Chromium-Browsern funktionieren. Er erklärt, wann man welches einsetzen sollte, und behandelt die typischen Fallstricke (Einzeilenverarbeitung, Blockierung durch Content-Security-Policy, Same-Origin-Beschränkungen), bevor gezeigt wird, wie man eigene Bookmarklets schreibt.

Jedes Bookmarklet lässt sich auf zwei Wegen installieren: Entweder ein neues Lesezeichen anlegen und den javascript:-Code als URL einfügen, oder einen Link, dessen href den Code enthält, auf die Lesezeichenleiste ziehen. Jedes der folgenden Snippets ist bereits eine einzelne Zeile – einfach so einfügen.

1. Jede Seite mit Design Mode live bearbeiten

Die gesamte Seite in ein bearbeitbares Dokument verwandeln, um Texte, Abstände und Layout auf einer Live-Website zu testen – ohne DevTools öffnen zu müssen:

javascript:document.designMode="on";void 0;

Das Setzen von document.designMode auf "on" macht das gesamte Dokument bearbeitbar – derselbe Effekt wie contenteditable="true", aber auf die gesamte Seite angewendet statt auf ein einzelnes Element. Einfach in eine Überschrift oder einen Absatz klicken und tippen. Dieses Bookmarklet ist ideal, wenn ein Stakeholder fragt: „Was wäre, wenn dieser Button X stünde?”, oder wenn man prüfen möchte, ob ein längerer Produktname die Navigationsleiste sprengt – ohne die Codebasis anzufassen.

Das abschließende void 0 ist wichtig. Eine javascript:-URL, die mit einem String endet, wird vom Browser als HTML-Dokument behandelt, zu dem navigiert wird; void 0 erzwingt einen Nicht-String-Rückgabewert, sodass die Seite bestehen bleibt. Soll nur ein bestimmter Bereich bearbeitbar sein? Dann einfach ersetzen durch: javascript:void(document.body.contentEditable=true).

2. Jedes Element einfärben, um das Layout zu debuggen

Die Box-Grenzen aller Elemente auf einmal sichtbar machen – unverzichtbar, um Overflow, Fehlausrichtungen und unerwünschte Abstände zu erkennen:

javascript:document.querySelectorAll("*").forEach(e=>e.style.background="rgb(0 0 0 / 10%)");void 0;

Dieses Bookmarklet wendet einen schwarzen Hintergrund mit 10 % Deckkraft auf jedes Element der Seite an. Da sich die halbtransparenten Ebenen überlagern, werden verschachtelte Elemente progressiv dunkler dargestellt – so lässt sich die DOM-Tiefe auf einen Blick ablesen, und man sieht sofort, welcher Container breiter als sein übergeordnetes Element ist. Wer harte Kanten statt schattierter Flächen bevorzugt, ersetzt die Hintergrundzeile durch einen Outline-Rahmen: e.style.outline="1px solid rgb(255 0 0 / 40%)". Outlines beeinflussen das Layout nicht – im Gegensatz zu Borders nehmen sie keinen Platz im Box-Modell ein – sodass die zu debuggende Seitengeometrie erhalten bleibt.

3. Maskierte Passwortfelder aufdecken

Alle Passwortfelder auf Klartext umschalten:

javascript:(()=>{document.querySelectorAll('input[type=password]').forEach(el=>el.type='text')})();

Dieses Bookmarklet durchläuft alle input[type=password]-Elemente und ändert deren type auf text, wodurch der aktuelle Wert sichtbar wird. Es empfiehlt sich beim Debuggen eines Authentifizierungsformulars, beim Überprüfen, was ein Passwort-Manager oder der Browser-Autofill tatsächlich eingetragen hat, oder beim Bestätigen, dass beim Einfügen kein nachgelagertes Leerzeichen übernommen wurde. Es liest den Live-DOM auf dieselbe Weise wie ein seiteninterner Debugger – Session-Replays fehlgeschlagener Login-Abläufe zeigen häufig, dass Autofill einen subtil falschen Wert eingetragen hat, und dies ist der schnellste manuelle Weg, diese Art von Fehler zu bestätigen.

4. Jede Farbe auf dem Bildschirm mit dem nativen Eyedropper aufnehmen

Beliebige Pixel auf dem Bildschirm auswählen und den Hex-Wert ermitteln:

javascript:void(async()=>{try{prompt('HEX:',(await new EyeDropper().open()).sRGBHex)}catch(e){alert(e)}})()

Dieses Bookmarklet ruft die EyeDropper API auf, die den Cursor in eine Lupe mit Farbwähler verwandelt; die ausgewählte Farbe wird als sRGBHex zurückgegeben und in einem prompt angezeigt, aus dem sie kopiert werden kann. Ein wichtiger Hinweis: Die EyeDropper API ist ausschließlich in Chromium-Browsern (Chrome und Edge) verfügbar, nur in sicheren Kontexten (HTTPS), und Firefox sowie Safari unterstützen sie Stand 2026 nicht. Außerdem erfordert sie eine Benutzerinteraktion – open() wirft eine Exception, wenn es nicht durch eine transiente Benutzeraktivierung ausgelöst wird – aber ein Bookmarklet-Klick ist eine Benutzergeste, sodass es sauber ausgeführt wird. Der try/catch-Block fängt die Ablehnung ab, die entsteht, wenn man Esc drückt statt eine Farbe auszuwählen.

5. Mobile DevTools mit eruda einbinden

Eine vollständige Konsole und einen DOM-Inspektor auf jeder Seite bereitstellen – auch auf einem Smartphone ohne DevTools:

javascript:(function(){var s=document.createElement('script');s.src='https://cdn.jsdelivr.net/npm/eruda';s.onload=function(){eruda.init()};document.head.appendChild(s)})();

Dieses Bookmarklet fügt ein <script>-Element ein, das eruda lädt – eine Konsole für mobile Browser, deren aktuelles Stable-Release 3.4.3 ist – und ruft nach dem Laden eruda.init() auf, wodurch ein DevTools-Panel über der Seite eingeblendet wird. Es ist besonders wertvoll beim Debuggen auf echten Geräten, an die kein Desktop-Inspektor angehängt werden kann. Zwei Dinge sind zu beachten: Die ungepinnte URL cdn.jsdelivr.net/npm/eruda liefert immer den zuletzt veröffentlichten Build, und erdas Release-Kadenz hat sich verlangsamt (seit über einem Jahr keine neue npm-Version), weshalb es als stabil, aber nicht aktiv gepflegt einzustufen ist. Da dieses Bookmarklet ein externes Skript lädt, unterliegt es der im nächsten Abschnitt beschriebenen CSP-Beschränkung.

Warum wird mein Bookmarklet nicht ausgeführt?

Vier Fehlerquellen sind für nahezu alle Fälle von „es funktioniert einfach nicht” verantwortlich:

Der CSP-Fall ist der wichtigste: Auf einer Website mit strikter Content-Security-Policy – das eruda-Bookmarklet auf GitHub im Vergleich zu einer permissiven Seite ausprobieren, um den Unterschied zu sehen – erscheint die Konsole schlicht nicht, und stattdessen wird eine CSP-Verletzung in der (echten) Konsole protokolliert. Auch die javascript:-Navigation selbst kann durch script-src blockiert werden.

Wie schreibt man ein eigenes Bookmarklet?

Um ein eigenes Bookmarklet zu schreiben, den Code in einem IIFE innerhalb einer javascript:-URL einschließen und DOM-verändernde Ausdrücke mit void 0 abschließen, damit die Seite nicht zu einem stringifizierten Rückgabewert navigiert:

javascript:(function(){/* your code here */})();

Der IIFE hält die eigenen Variablen aus dem globalen Scope der Seite heraus, und javascript:foo() wird üblicherweise mit void präfigiert, um versehentliche Navigation zu verhindern, falls der Aufruf einen String zurückgibt. Die Logik zunächst in der DevTools-Konsole schreiben und debuggen, dann auf eine Zeile zusammenfassen – dabei //-Kommentare entfernen – und als URL des Lesezeichens einfügen. Alles, was man in die Konsole eingeben kann, lässt sich als Ein-Klick-Bookmarklet mitnehmen.

FAQs

Warum hört mein Bookmarklet mitten im Code auf zu funktionieren?

Ein Bookmarklet ist eine einzelne Zeile, daher macht ein //-Zeilenkommentar alle nachfolgenden Zeichen wirkungslos – einschließlich der schließenden Klammern und Funktionsaufrufe. Alle //-Kommentare durch /* Block */-Kommentare ersetzen oder vollständig entfernen. Beim Zusammenfassen von mehrzeiligem Konsolencode zu einem Bookmarklet zuerst alle //-Kommentare entfernen, da der Zeilenumbruch, der sie normalerweise beendet, in einer einzelnen Zeile nicht mehr existiert.

Was ist der Unterschied zwischen designMode und contentEditable in einem Bookmarklet?

Das Setzen von document.designMode auf 'on' macht das gesamte Dokument mit einer einzigen Anweisung bearbeitbar, während contentEditable pro Element gesetzt wird – document.body.contentEditable = true macht also nur den Body-Bereich bearbeitbar. designMode verwenden, wenn man in beliebige Überschriften, Absätze oder Buttons auf der gesamten Seite klicken möchte; contentEditable verwenden, wenn die Bearbeitung auf einen einzelnen Container beschränkt werden soll und der Rest der Seite unverändert bleiben soll.

Funktioniert das EyeDropper-Bookmarklet in Firefox oder Safari?

Nein. Die EyeDropper API ist ausschließlich für Chromium-Browser verfügbar und funktioniert in Chrome und Edge nur über HTTPS in einem sicheren Kontext; Firefox und Safari unterstützen sie Stand 2026 nicht. Die API erfordert außerdem eine transiente Benutzeraktivierung, aber ein Bookmarklet-Klick zählt als Benutzergeste, sodass open() auf diesem Weg sauber ausgeführt wird. In nicht unterstützten Browsern wirft das Bookmarklet eine Exception, da der EyeDropper-Konstruktor nicht definiert ist.

Kann ein Bookmarklet Cross-Origin-Fetch-Anfragen stellen?

Nicht ohne Weiteres. Ein fetch()-Aufruf innerhalb eines Bookmarklets läuft im Kontext der aktuellen Seite und unterliegt daher der Same-Origin-Policy sowie der CSP-connect-src-Direktive der Website. Anfragen an einen anderen Origin werden blockiert, sofern dieser Endpunkt keine korrekten CORS-Header sendet. Netzwerkanfragen in Bookmarklets auf denselben Origin wie die Seite oder auf CORS-fähige APIs beschränken; es gibt keine clientseitige Umgehungsmöglichkeit für die Policy einer Website.