Chrome Themes 2026: Installieren, selbst bauen und die Grenzen — mit echten Messungen

Chrome Themes sind die einfachste Art, den Browser umzufärben — und gleichzeitig das am gründlichsten missverstandene Stück der Chrome-Anpassung. Fast jede Anleitung im Netz zeigt dieselben zehn hübschen Themes, erklärt den Klick auf „Hinzufügen” und hört genau dort auf, wo es interessant wird.

Dieser Artikel macht es anders. Wir haben nicht recherchiert, sondern gemessen: 661 Einträge aus dem Chrome Web Store heruntergeladen, entpackt, ihre Manifeste auseinandergenommen und die Farben von 506 echten Themes durch einen WCAG-Kontrastrechner geschickt. Dann haben wir ein eigenes Theme gebaut — und anschließend systematisch versucht, es kaputtzumachen, um herauszufinden, was Chrome eigentlich prüft.

Zwei Ergebnisse vorweg, und beide sind unangenehm. Erstens: Bei 36,3 % der Themes liegt mindestens eine Text-auf-Hintergrund-Kombination unter Kontrast 3,0 — bei 46 Themes ist sie exakt 1,00, also buchstäblich unsichtbarer Text. Zweitens: Ein vollständiges, funktionierendes Chrome Theme ist am Ende 619 Byte groß. Eine einzige Datei. Kein Build-Prozess, kein Framework, keine Zeile JavaScript.

Die Kurzfassung

Methodik: Alle Zahlen am 03.09.2026 erhoben. 661 Store-Einträge über 74 Theme-bezogene Suchanfragen im Chrome Web Store gesammelt, per Update-Endpunkt als CRX heruntergeladen (661 von 661 erfolgreich), entpackt und ihre manifest.json ausgewertet. Kontraste nach WCAG 2.1 (relative Luminanz) berechnet; Alphawerte wurden gegen den jeweiligen Hintergrund verrechnet statt verworfen. Farbschlüssel aus chrome/browser/themes/browser_theme_pack.cc und chrome/common/extensions/manifest_handlers/theme_handler.cc von chromium/chromium gezählt. Ladeverhalten getestet mit Google Chrome 149.0.7827.102, Chrome for Testing 151.0.7922.34 und Chromium 152.0.7977.64.

Was ein Chrome Theme eigentlich ist

Ein Chrome Theme ist eine Erweiterung — technisch gesehen. Es liegt im selben Format, wird über denselben Store verteilt und landet im selben Verzeichnis. Der einzige Unterschied: Statt Code enthält es einen theme-Block im Manifest.

Das klingt nach einer Formalie, ist aber der wichtigste Satz des ganzen Artikels. Denn in Chromiums Quellcode ist theme ein eigener Erweiterungstyp:

"theme": {
  "channel": "stable",
  "extension_types": ["theme"]
}

Ein Paket ist entweder ein Theme oder eine Erweiterung. Es kann nicht beides sein. Und daraus folgt die Eigenschaft, die Themes zur mit Abstand sichersten Kategorie im gesamten Web Store macht: Ein Theme kann keine Berechtigungen anfordern. Kein storage, kein tabs, kein Zugriff auf besuchte Seiten. Es hat keinen Hintergrundprozess, kein Content-Script, keine Möglichkeit, irgendetwas zu lesen.

Wir haben das nicht geglaubt, sondern nachgezählt. Von den 506 echten Themes im Korpus deklarieren genau vier überhaupt irgendetwas in Richtung Berechtigung — und in allen vier Fällen sind es tote Einträge, die Chrome für einen Theme-Typ schlicht ignoriert. Praktisch heißt das: Wer ein Theme installiert, installiert eine Farbtabelle.

Der Fund, nach dem niemand gesucht hat: jedes vierte „Theme” ist keins

Wir haben unseren Korpus über Theme-Suchen im Store zusammengetragen — „theme”, „dark theme”, „minimal theme”, „catppuccin”, „amoled”, 74 Anfragen insgesamt. Dann haben wir jedes Paket geöffnet und nachgesehen, ob überhaupt ein theme-Block drin ist.

Von 661 Treffern sind 155 keine Themes — 23,4 %. Es sind normale Erweiterungen, die bei Theme-Suchen auftauchen, weil sie „Theme” oder „Dark Mode” im Namen tragen.

Das wäre eine Kuriosität, wenn der Unterschied kosmetisch wäre. Ist er aber nicht. Diese 155 Erweiterungen fordern zusammen genau das an, was ein echtes Theme technisch nicht kann:

31 Suchergebnisse für „Theme” wollen jede Website lesen, die man besucht. Darunter Einträge, die schlicht „Dark Mode”, „High Contrast” oder „night theme for web” heißen — Namen, die exakt nach dem klingen, was ein harmloses Theme wäre.

Manche davon sind völlig legitim: Ein Dark-Mode-Umfärber muss Seiten lesen können, um sie umzufärben. Das ist kein Vorwurf. Der Punkt ist ein anderer: Die Suchergebnisliste unterscheidet die beiden Dinge nicht, und die Kachel im Store sieht in beiden Fällen gleich aus. Ein Nutzer, der „dark theme” sucht und auf das erste hübsche Ergebnis klickt, kann mit einem Klick von „ändert die Farbe meiner Tableiste” zu „liest jede Seite, die ich öffne” wechseln, ohne dass sich an der Oberfläche etwas ändert.

Die verlässliche Unterscheidung braucht keine Fachkenntnis: Chrome zeigt beim Installieren einer echten Theme-Datei keine Berechtigungsabfrage. Erscheint eine — „Diese Erweiterung kann Ihre Daten auf allen Websites lesen und ändern” —, dann ist es kein Theme, egal was der Name sagt. Wer tiefer prüfen will, findet dieselbe Information auf der Store-Seite unter „Datenschutzpraktiken”.

Wer generell wissen will, welchen Browser er sich damit einrichtet, findet in unserem Vergleich quelloffener Webbrowser den größeren Rahmen dazu.

Die 26 Farben — und woher wir wissen, dass es 26 sind

Die meisten Anleitungen zählen Chrome-Theme-Farben ab, indem sie von anderen Anleitungen abschreiben. Wir haben stattdessen im Quellcode nachgesehen. In browser_theme_pack.cc steht die maßgebliche Tabelle, mit einem bemerkenswert ehrlichen Kommentar darunter:

// Strings used by themes to identify colors in the JSON.
constexpr StringToIdTable<TP::OverwritableByUserThemeProperty>
    kOverwritableColorTable[] = {
        {"frame", TP::COLOR_FRAME_ACTIVE},
        {"toolbar", TP::COLOR_TOOLBAR},
        {"tab_text", TP::COLOR_TAB_FOREGROUND_ACTIVE_FRAME_ACTIVE},
        // ... 23 weitere
        // /!\ If you make any changes here, you must also increment
        // kThemePackVersion above, or else themes will display incorrectly.
};

Ausgezählt sind das 26 überschreibbare Farbschlüssel. Daneben liegt eine zweite Tabelle mit 11 Farben, die Chrome selbst berechnet und die ein Theme nicht setzen kann — darunter die Farbe des Ladekringels und die Fensterknöpfe. Dazu kommen 6 Tints, 15 Bildslots und 3 Display-Properties.

Zum Vergleich: Firefox stellt 42 Farbschlüssel bereit. Chrome gibt also deutlich weniger Kontrolle — wer in unseren Firefox-Themes-Artikel schaut, sieht denselben Aufbau mit spürbar mehr Stellschrauben.

Was in der Praxis tatsächlich benutzt wird, ist noch einmal viel weniger. Über alle 506 Themes gezählt:

Der Median liegt bei 9 Farben pro Theme, das Minimum bei 2, das Maximum bei 42 — wobei die Themes mit über 26 Farben nur deshalb so hoch kommen, weil sie Schlüssel setzen, die es gar nicht gibt. Dazu gleich mehr.

Praktische Konsequenz: Sieben Farben decken über 90 % dessen ab, was echte Themes tun. Wer ein Theme baut, braucht keine 26 Zeilen.

Das Experiment: Was prüft Chrome eigentlich?

Hier wird es interessant. Wir haben 15 Themes gebaut, jedes mit einem gezielt eingebauten Defekt, und jedes einzeln in Chrome for Testing 151 geladen. Danach haben wir im Profil nachgesehen, ob das Theme tatsächlich als aktives Theme registriert wurde — nicht, ob der Browser eine Erfolgsmeldung ausgegeben hat.

Das Muster ist eindeutig, und es steht wörtlich im Quellcode. theme_handler.cc prüft beim Laden der Farben genau drei Dinge:

// Validate that the colors are RGB or RGBA lists.
if (!value.is_list()) { *error = errors::kInvalidThemeColors; return false; }
// There must be either 3 items (RGB), or 4 (RGBA).
if (!(color_list.size() == 3 || color_list.size() == 4)) { ... }
// The first three items (RGB), must be ints:
if (!(color_list[0].is_int() && ...)) { ... }

Ist es eine Liste? Hat sie 3 oder 4 Einträge? Sind die ersten drei Ganzzahlen? Das war die gesamte Prüfung. Der Wertebereich wird nie geprüft. Die Schlüsselnamen werden nie mit der Tabelle abgeglichen. Ob das Ergebnis lesbar ist, interessiert niemanden.

Die Prüfung ist eine Aussage über die Form, nicht über den Inhalt. Ein Theme mit [999, -40, 300] lädt sauber; Chrome klemmt die Werte später still auf den gültigen Bereich. Ein Theme mit dem Tippfehler tolbar lädt ebenfalls sauber — die Zeile wird beim Aufbau der Farbtabelle einfach nicht gefunden und verschwindet lautlos.

Ein aufschlussreicher Sonderfall war C8 gegen C11. C8 (unbekannter Bildslot) wurde abgelehnt — auf den ersten Blick sah das so aus, als prüfe Chrome doch die Bildnamen. Die naheliegende Schlussfolgerung wäre falsch gewesen. C11 ist derselbe unbekannte Slot, nur mit einer tatsächlich vorhandenen Datei daneben — und der lädt problemlos. C8 scheiterte also nicht am Namen, sondern an der fehlenden Datei. Ein Test mit zwei gleichzeitigen Defekten sagt nicht, welcher der beiden das Ergebnis verursacht hat. Erst der zweite Durchlauf hat das getrennt.

Bemerkenswert ist dabei, was Chrome doch hart abfängt: fehlende Bilddateien (C7, C8). Das ist strenger als der VS-Code-Packer vsce, der in unserem Test der VS-Code-Themes einen Verweis auf eine nicht existierende Datei stillschweigend mit einpackte.

Der Beleg aus der Praxis: 21 % der Themes enthalten Schlüssel, die es nicht gibt

Wenn Chrome unbekannte Farbschlüssel lautlos ignoriert, dann müssten im Store Themes stehen, die genau das tun — ohne dass es je jemandem aufgefallen ist. Genau so ist es.

108 der 506 Themes (21,3 %) setzen mindestens eine Farbe, die Chrome gar nicht kennt. Die häufigsten:

Das ist kein Zufall und keine reine Schlamperei: ntp_section und Verwandte waren einmal echte Schlüssel für die alte „Neuer Tab”-Seite. Sie wurden aus Chrome entfernt, aber niemand hat es den Theme-Autoren gesagt — weil es nichts gibt, das es ihnen sagen könnte. Kein Fehler, keine Warnung, keine Store-Ablehnung. Die Zeile steht weiter im Manifest, sieht weiter richtig aus und tut seit Jahren nichts.

Dazu kommen 5 Themes mit ungültigem Bildslot, 6 mit erfundenen Properties und 3 mit doppelten JSON-Schlüsseln — bei „Green theme” stehen ntp_text und toolbar jeweils zweimal im selben Objekt, mit unterschiedlichen Werten. JSON erlaubt das formal nicht eindeutig; in der Praxis gewinnt der letzte. Der Autor sieht im Editor die erste Farbe und im Browser die zweite.

Die eigentliche Messung: Kontrast

Jetzt zum Teil, der Nutzer tatsächlich betrifft. Wir haben für jedes Theme die Farbpaare berechnet, die im Browser wirklich übereinanderliegen — Tab-Text auf Toolbar, Lesezeichentext auf Toolbar, inaktiver Tab-Text auf Rahmen, und die Farben der Neuer-Tab-Seite. Berechnet nach WCAG 2.1, mit gegen den Hintergrund verrechneten Alphawerten.

Über alle Paare zusammengefasst: Bei 50,2 % der Themes liegt mindestens ein Paar unter AA, bei 36,3 % unter 3,0 — und bei 46 Themes ist mindestens ein Paar exakt 1,00.

Kontrast 1,00 bedeutet: identische Farbe. Der Text ist nicht schlecht lesbar, er ist nicht vorhanden.

Weil das eine harte Aussage ist, haben wir die Extremfälle einzeln von Hand nachgerechnet statt dem Skript zu glauben:

• „Acrylic Watercolor”: toolbar = [255,255,255], tab_text = [255,255,255]. Weiß auf Weiß. Bewertung im Store: 4,77 Sterne.
• „Pink Leopard Hearts”: toolbar, bookmark_text und tab_background_text alle drei [231,92,173]. Der komplette Lesezeichen-Text verschwindet im Hintergrund. Bewertung: 4,82 Sterne bei 55 Stimmen.
• „Jungle Gem – High Contrast Dark Theme”: toolbar = [0,0,0], tab_text = [0,0,0]. Schwarz auf Schwarz — in einem Theme, das „High Contrast” im Namen führt.

Der letzte Fall ist kein Einzelfall, sondern ein Muster, das wir schon bei VS Code gefunden hatten: „High Contrast” im Namen ist ein Versprechen ohne Deckung. Beide Themes im Korpus mit diesem Namensbestandteil fallen durch — eines bei 1,00, das andere bei 2,19.

Und der Befund, der am meisten weh tut: 17 Themes mit Kontrast unter 3,0 haben gleichzeitig eine Bewertung von 4,5 Sternen oder besser bei mindestens 50 Stimmen. Darunter:

3.513 Menschen haben ein Theme mit unsichtbarem Text im Schnitt mit 4,8 von 5 bewertet. Das ist kein Vorwurf an diese Menschen. Es ist der Beleg dafür, dass Sternebewertungen diese Klasse von Fehler strukturell nicht finden: Ein Theme mit unlesbarem inaktivem Tab-Text sieht auf dem Store-Screenshot großartig aus, und im Alltag hält man die verschwundene Beschriftung für eine Designentscheidung, nicht für einen Defekt.

Größe: der Faktor 368

Die Spannweite im Korpus ist absurd. Das kleinste Theme („Baby Blue”) ist 2.879 Byte groß und besteht aus vier Farben:

{
  "frame":              [181, 211, 252],
  "frame_inactive":     [227, 237, 252],
  "toolbar":            [210, 227, 252],
  "omnibox_background": [255, 255, 255]
}

Das größte („Christmas decorations”) ist 27,3 MB groß — Faktor 9.470. Der Unterschied hat genau eine Ursache: Bilder.

Faktor 368. Ein reines Farbtheme ist im Median kleiner als ein durchschnittliches Icon; ein Bildtheme ist im Median größer als eine Musikdatei. Wer sein Theme klein halten will, hat genau eine Entscheidung zu treffen — und die trifft er in der ersten Minute.

Nebenbei: 194 der 506 Themes (38,3 %) laufen noch auf Manifest V2, 18 haben gar keine manifest_version. Bei Erweiterungen wäre das inzwischen ein Todesurteil — Themes hingegen sind von der MV3-Umstellung praktisch nicht betroffen, weil sie keinen Code enthalten, der migriert werden müsste. Ein Theme von 2012 funktioniert heute unverändert.

Ein eigenes Chrome Theme bauen

Das ist der einfachste Teil des Artikels. Man braucht einen Ordner und eine Datei.

{
  "manifest_version": 3,
  "name": "GetMind Cosmic",
  "version": "1.0",
  "theme": {
    "colors": {
      "frame":              [26, 27, 38],
      "frame_inactive":     [36, 37, 48],
      "toolbar":            [36, 40, 59],
      "tab_text":           [192, 202, 245],
      "tab_background_text":[138, 145, 178],
      "bookmark_text":      [192, 202, 245],
      "toolbar_text":       [192, 202, 245],
      "omnibox_background": [26, 27, 38],
      "omnibox_text":       [192, 202, 245],
      "ntp_background":     [26, 27, 38],
      "ntp_text":           [192, 202, 245],
      "ntp_link":           [122, 162, 247]
    },
    "properties": {
      "ntp_logo_alternate": 1
    }
  }
}

Das ist das vollständige Theme: 619 Byte, eine Datei, zwölf Farben. Es enthält kein Bild, keinen Code, keine Berechtigung.

Installieren:

1. chrome://extensions öffnen
2. Rechts oben Entwicklermodus einschalten
3. Entpackte Erweiterung laden → den Ordner auswählen

Der Kommandozeilen-Weg --load-extension=/pfad steht in vielen Anleitungen. Er funktioniert in aktuellen Chrome-Versionen nicht mehr. Wir haben es in Chrome 149 getestet und im Log steht wörtlich:

--load-extension is not allowed in Google Chrome, ignoring.

Der Prozess startet trotzdem und beendet sich mit Exit-Code 0 — es gibt keinerlei sichtbaren Fehler. Nur das Theme ist eben nicht da. In Chrome for Testing und Chromium funktioniert das Flag weiterhin; alle unsere Ladetests laufen deshalb dort.

Wichtig zur Theme-ID: Wir haben dasselbe Manifest aus zwei verschiedenen Ordnern geladen und zwei verschiedene IDs bekommen (kaofli… und kfdlee…). Bei einer entpackten Erweiterung leitet Chrome die ID aus dem Pfad ab, nicht aus dem Inhalt. Wer sein Theme verschiebt, bekommt für Chrome ein anderes Theme.

Die eigenen Farben prüfen — weil Chrome es nicht tut

Da Chrome den Inhalt nachweislich nicht prüft, muss man es selbst tun. Die Rechnung ist kurz genug, um sie in ein paar Zeilen zu schreiben:

def _lin(c):
    c = c / 255.0
    return c / 12.92 if c <= 0.04045 else ((c + 0.055) / 1.055) ** 2.4

def luminanz(rgb):
    r, g, b = rgb[:3]
    return 0.2126 * _lin(r) + 0.7152 * _lin(g) + 0.0722 * _lin(b)

def kontrast(vordergrund, hintergrund):
    a, b = luminanz(vordergrund), luminanz(hintergrund)
    if a < b:
        a, b = b, a
    return (a + 0.05) / (b + 0.05)

# Unser Theme gegengeprüft:
kontrast([192, 202, 245], [36, 40, 59])   # Tab-Text auf Toolbar → 9,49
kontrast([138, 145, 178], [26, 27, 38])   # inaktiver Tab auf Rahmen → 6,81
kontrast([122, 162, 247], [26, 27, 38])   # NTP-Link auf NTP → 7,29

Diese Implementierung haben wir gegen bekannte Referenzwerte geprüft, bevor wir ihr 506 Themes anvertraut haben: Weiß auf Schwarz muss exakt 21,00 ergeben, #767676 auf Weiß exakt 4,54 (der offizielle AA-Grenzfall). Beides stimmt auf die zweite Nachkommastelle. Ein Messgerät, das man nicht gegen einen bekannten Wert gehalten hat, misst nur die eigene Überzeugung.

Die drei Paare, die man prüfen muss — mehr braucht es nicht:

1. tab_text gegen toolbar (aktiver Tab)
2. tab_background_text gegen frame (inaktive Tabs — hier ist die Fehlerquote mit 36,8 % am höchsten)
3. ntp_text gegen ntp_background (Neuer Tab)

Zielwert 4,5 für normalen Text. Wer darunter landet, sollte es zumindest wissen — genau wie beim Kontrast in Code-Editoren, wo dieselbe Blindstelle ausgerechnet die Kommentarfarbe traf.

Chromium-Forks: dasselbe Manifest, andere ID

Wir haben unser unverändertes Theme zusätzlich in Chromium 152 geladen. Es funktioniert ohne jede Anpassung — dieselbe manifest.json, dieselben Farben, kein Kompatibilitätsschalter. Das gilt entsprechend für Brave, Edge, Vivaldi und Opera, die alle auf derselben Codebasis sitzen.

Zwei Einschränkungen, die man kennen sollte:

• Die ID unterscheidet sich zwischen den Browsern, weil sie pfadabhängig ist. Für den Nutzer irrelevant, für Skripte nicht.
• Der Store unterscheidet sich. Edge hat einen eigenen Add-ons-Store, Vivaldi bringt eigene Themes mit einem völlig anderen (und deutlich mächtigeren) Mechanismus mit. Ein Chrome Theme läuft überall, ist aber in manchen Forks nicht die naheliegendste Lösung.

Wer sich für die Unterschiede zwischen den Browsern jenseits der Farben interessiert: Der Open-Source-Browser-Vergleich geht auf Engine, Datenschutz und Update-Politik ein.

Veröffentlichen im Chrome Web Store

Wer sein Theme nur selbst nutzen will, ist oben fertig. Für die Veröffentlichung gilt:

1. Entwicklerkonto anlegen — einmalige Gebühr von 5 US-Dollar.
2. Ordner als ZIP packen. Kein spezielles Werkzeug nötig; der Store nimmt ein normales ZIP.
3. Icon beilegen. Formal optional, praktisch unverzichtbar — sonst zeigt der Store einen Platzhalter.
4. Hochladen und auf die Prüfung warten. Themes werden in der Regel schneller geprüft als Erweiterungen, weil kein Code zu analysieren ist.

Was die Prüfung nicht macht: Sie prüft weder Kontraste noch Farbschlüssel. Die 108 Themes mit ungültigen Schlüsseln und die 46 mit unsichtbarem Text sind alle durch diese Prüfung gekommen.

Bei entpackten Erweiterungen entsteht die ID aus dem Pfad — bei hochgeladenen aus dem Signaturschlüssel, den der Store vergibt. Diese ID ist dauerhaft und lässt sich nicht ändern.

Grenzen: Was ein Chrome Theme nicht kann

Hier hört die Ehrlichkeit vieler Anleitungen auf. Ein Theme kann:

• die Fensterleiste, die Tableiste und die Toolbar einfärben
• Hintergrundbilder in Rahmen, Toolbar und Neuer-Tab-Seite setzen
• die Farben der Neuer-Tab-Seite bestimmen

Ein Theme kann nicht:

• Websites verändern (das braucht ein Content-Script — also eine echte Erweiterung mit Seitenzugriff)
• das Kontextmenü, die Einstellungsseiten oder chrome://-Seiten umfärben
• Schriftarten oder Abstände ändern
• Rundungen, Tab-Formen oder Layout beeinflussen
• eine dunkle Oberfläche in Dialogen erzwingen

Der letzte Punkt ist die häufigste Enttäuschung: Ein dunkles Theme macht die Tableiste dunkel, aber viele Menüs bleiben hell, weil sie dem Betriebssystem-Modus folgen. Und Firefox’ userChrome.css, mit dem sich in Firefox praktisch jedes Detail umbauen lässt, hat in Chrome kein Gegenstück. Wer wirklich tief eingreifen will, ist bei Chrome an der falschen Adresse — das ist einer der wenigen Punkte, an denen Firefox technisch klar mehr erlaubt.

Häufige Fragen

Ist ein Chrome Theme gefährlich?

Ein echtes Theme ist die sicherste Kategorie im Store: Es kann technisch keine Berechtigungen anfordern, hat keinen Hintergrundprozess und kein Content-Script. Von 506 geprüften Themes hatte praktisch keines echten Datenzugriff. Vorsicht ist bei Suchergebnissen geboten, die nur wie Themes heißen — 23,4 % unserer Treffer waren Erweiterungen, 31 davon wollten jede Website lesen.

Woran erkenne ich, ob ein „Theme” wirklich ein Theme ist?

An der Berechtigungsabfrage: Bei einem echten Theme erscheint keine. Fragt Chrome beim Installieren nach Zugriff auf Websites, ist es eine Erweiterung — unabhängig vom Namen. Zweite Prüfung: der Abschnitt „Datenschutzpraktiken” auf der Store-Seite.

Wie viele Farben kann ein Chrome Theme setzen?

26 überschreibbare Farbschlüssel, dazu 6 Tints, 15 Bildslots und 3 Display-Properties. Weitere 11 Farben berechnet Chrome selbst und lässt sie nicht überschreiben. In der Praxis nutzt ein typisches Theme davon nur 9.

Prüft Chrome, ob meine Theme-Farben lesbar sind?

Nein. Chrome prüft nur, ob ein Farbwert eine Liste mit 3 oder 4 Einträgen ist und ob die ersten drei Ganzzahlen sind. Wertebereich, Schlüsselnamen und Lesbarkeit werden nie geprüft. Unser Test mit Weiß auf Weiß wurde anstandslos geladen, ebenso Werte wie [999, -40, 300].

Warum funktioniert eine Farbe in meinem Theme nicht?

Höchstwahrscheinlich heißt der Schlüssel anders, als du denkst — ein Tippfehler oder ein Schlüssel aus einer alten Chrome-Version. Chrome ignoriert unbekannte Schlüssel still, ohne Fehlermeldung. Bei 21,3 % der Themes im Store steht mindestens ein solcher toter Schlüssel im Manifest, am häufigsten ntp_section.

Wie groß muss ein Chrome Theme sein?

So klein wie du willst. Unser vollständiges Theme ist 619 Byte groß, das kleinste im Store 2.879 Byte. Themes ohne Bild sind im Median 3.913 Byte groß, Themes mit Bild 1,44 MB — Faktor 368.

Brauche ich Programmierkenntnisse für ein Chrome Theme?

Nein. Ein Theme enthält keine Zeile Code, nur eine manifest.json mit Farbwerten. Wer JSON lesen kann, kann ein Theme bauen; ein Build-Prozess existiert nicht.

Warum funktioniert --load-extension bei mir nicht?

Weil Google Chrome dieses Flag inzwischen ignoriert — im Log steht wörtlich „—load-extension is not allowed in Google Chrome”. Der Prozess startet trotzdem ohne Fehler. Nutze stattdessen chrome://extensions → Entwicklermodus → „Entpackte Erweiterung laden”, oder greife zu Chrome for Testing beziehungsweise Chromium.

Läuft mein Chrome Theme auch in Brave, Edge oder Vivaldi?

Ja, unverändert — alle basieren auf Chromium. Wir haben dasselbe Manifest in Chromium 152 gegengeprüft. Die Extension-ID unterscheidet sich allerdings, und Edge sowie Vivaldi haben eigene Stores und teils eigene Theme-Mechanismen.

Kann ein Theme das Aussehen von Websites ändern?

Nein. Ein Theme färbt ausschließlich die Browser-Oberfläche. Für Websites braucht es ein Content-Script — und damit eine echte Erweiterung mit Zugriff auf die besuchten Seiten. Genau das ist der Unterschied, der bei den 31 Suchergebnissen mit Vollzugriff sichtbar wurde.

Was ist das Chrome-Gegenstück zu userChrome.css?

Es gibt keins. Firefox erlaubt mit userChrome.css tiefe Eingriffe in die Browser-Oberfläche; Chrome bietet nur die 26 Farbschlüssel und die Bildslots. Wer Tab-Formen, Abstände oder Schriften ändern will, kommt mit einem Chrome Theme nicht ans Ziel.

Fazit

Chrome Themes sind gleichzeitig simpler und schlechter geprüft, als ihr Ruf vermuten lässt.

Simpler, weil ein vollständiges Theme aus einer einzigen Datei mit 619 Byte besteht. Kein Build, kein Framework, kein Code. Wer eine halbe Stunde Zeit hat, hat ein eigenes Theme.

Schlechter geprüft, weil Chrome ausschließlich die Form der Werte kontrolliert und nie ihren Inhalt. Das ist keine Vermutung, sondern steht in theme_handler.cc und ließ sich in 15 Ladetests reproduzieren: Weiß auf Weiß, Werte jenseits von 255, erfundene Schlüssel — alles wird angenommen. Die Folgen stehen im Store: 21,3 % der Themes tragen tote Farbschlüssel, 36,3 % haben mindestens ein kaum lesbares Farbpaar, 46 ein völlig unsichtbares.

Und weil ausgerechnet die beliebtesten dieser Themes exzellente Bewertungen haben — 4,80 Sterne bei 3.513 Stimmen für ein Theme mit unsichtbarem Text —, ist klar, dass weder die automatische Prüfung noch die Community diese Fehlerklasse findet. Der einzige Prüfer, der übrig bleibt, ist der Autor selbst.

Drei Kontrastrechnungen, zehn Zeilen Code, einmal vor der Veröffentlichung. Das ist der ganze Unterschied zwischen einem Theme, das hübsch aussieht, und einem, das man auch benutzen kann.