Shadcn Password Input: Anzeigen, Stärke und Caps Lock

Du brauchst ein Passwortfeld mit Augen-Icon, für die Registrierung vielleicht noch eine Stärkeanzeige, und suchst nach einem shadcn Password Input. Die erste Überraschung: shadcn/ui liefert keinen mit. Stand 5. November 2026 enthält die Komponentenliste von shadcn/ui (opens in a new tab) Input, Input Group und Field, aber keinen Password Input. Was du findest, sind Community-Snippets auf Basis von Input. Das Augen-Icon ist der einfache Teil. Ob das Feld für echte Menschen funktioniert, entscheiden andere Details: wohin der Cursor springt, wenn der Typ wechselt, ob ein Screenreader den Zustand hört, was Passwortmanager mitgeteilt bekommen und was bei aktivem Caps Lock passiert.

Dieser Guide geht diese Details mit dem Password Input von Wingo UI durch, der Bibliothek, die wir bauen. Wir sind also nicht neutral. Fakten von außen verlinken auf ihre Quellen.

Was muss ein shadcn Password Input können?

Unsere Checkliste für ein Login-Feld, noch bevor es um Passwortstärke geht:

• Ein echter Button zum Anzeigen. Ein <button type="button"> in der Tab-Reihenfolge, ein aria-label, das sagt, was er tut („Show password“, „Hide password“), und aria-pressed für den aktuellen Zustand.
• Der Cursor bleibt, wo er ist. Wenn type von password auf text wechselt, verwerfen manche Browser die Auswahl, und der Cursor springt ans Ende oder an den Anfang. Speicher selectionStart, selectionEnd und die Richtung vor dem Wechsel und stell sie danach wieder her.
• Passwortmanager bekommen den richtigen Hinweis. autocomplete="current-password" beim Login, "new-password" bei Registrierung und Passwortänderung.
• Der Browser lässt den Text in Ruhe. spellCheck={false}, autoCapitalize="none" und autoCorrect="off", damit sichtbarer Text weder unterstrichen noch großgeschrieben noch an eine Rechtschreibprüfung geschickt wird. Der Password Input von GOV.UK (opens in a new tab) setzt spellcheck und autocapitalize genauso (geprüft am 5. November 2026).
• Caps Lock ist sichtbar. Eine kurze Warnung unter dem Feld, solange Caps Lock an ist und das Feld den Fokus hat.
• Smartphones funktionieren. Eine Schriftgröße von 16px, damit iOS nicht zoomt, 44px große Trefferflächen für die Icon-Buttons und ein enterKeyHint, der zum nächsten Schritt passt („go“ beim Login, „next“ bei der Registrierung).

Die Komponente von Wingo UI erfüllt jeden Punkt dieser Liste schon mit den Standardwerten:

npx wingo-ui@latest add password-input

import { PasswordInput } from "@/components/ui/password-input"

export function PasswordField() {
  return (
    <PasswordInput
      name="password"
      label="Passwort"
      placeholder="Dein Passwort"
      required
      fieldProps={{ labelAction: <a href="/forgot-password">Passwort vergessen?</a> }}
    />
  )
}

label, description und error kommen vom gemeinsamen Field-Wrapper. Das Label ist also über htmlFor verknüpft, der Hinweis über aria-describedby, und ein Fehler ersetzt den Hinweis und setzt aria-invalid. fieldProps.labelAction setzt den Link „Passwort vergessen?“ in die Label-Zeile, wo man ihn sucht.

Wie baue ich einen shadcn Password Input Show/Hide-Toggle, der den Cursor hält?

Ein typisches Snippet zu „shadcn Password Input Show Hide“ besteht aus einem useState-Boolean, einem absolut positionierten Button und type={visible ? "text" : "password"}. Das klappt so lange, bis jemand mitten in einem langen Passwort etwas ändert, es zur Kontrolle anzeigt und an der falschen Stelle weitertippt. Die Lösung hat drei Schritte:

1. Lies beim Klick selectionStart, selectionEnd und selectionDirection, solange das Input noch den Fokus hat.
2. Schalte den Zustand um.
3. Ruf in einem Layout-Effekt, der von der Sichtbarkeit abhängt, setSelectionRange mit den gespeicherten Werten auf und im nächsten Animation Frame gleich noch einmal, weil Chrome die Auswahl nach einem echten Mausklick ein zweites Mal zurücksetzt.

Der Button ruft außerdem preventDefault() bei pointerdown und mousedown auf, damit das Input beim Klick nicht zuerst den Fokus verliert. Sonst gibt es keine fokussierte Auswahl mehr, die man speichern könnte. Die Wingo-Komponente erledigt das alles intern. Die Sichtbarkeit steuerst du nur, wenn du es wirklich brauchst, zum Beispiel für eine Checkbox, die zwei Felder auf einmal anzeigt:

"use client"

import { useState } from "react"
import { Checkbox } from "@/components/ui/checkbox"
import { PasswordInput } from "@/components/ui/password-input"

export function RouterPasswords() {
  const [visible, setVisible] = useState(false)
  return (
    <div className="flex flex-col gap-4">
      <PasswordInput label="WLAN-Passwort" visible={visible} onVisibleChange={setVisible} showToggle={false} />
      <PasswordInput label="Admin-Passwort" visible={visible} onVisibleChange={setVisible} showToggle={false} />
      <Checkbox label="Passwörter anzeigen" checked={visible} onCheckedChange={(c) => setVisible(c === true)} />
    </div>
  )
}

Gehört der Augen-Button in die Tab-Reihenfolge?

Ja. Manche Snippets setzen tabIndex={-1}, damit Tab vom Passwort direkt zum Absende-Button springt. Damit verschwindet der Button zum Passwort anzeigen für alle, die mit Tastatur oder Schaltern arbeiten, also für genau die Menschen, die am ehesten prüfen wollen, was sie getippt haben. Lass ihn fokussierbar, gib ihm ein aria-label und setz aria-pressed. Dann sagt ein Screenreader ihn als Toggle-Button mit Label und gedrücktem Zustand an. In der Wingo-Komponente folgt das Label dem Zustand („Show password“, solange das Passwort verborgen ist, „Hide password“, solange es sichtbar ist), und der Button trägt aria-controls mit Verweis auf das Input. Die Texte änderst du mit showLabel und hideLabel, die Lucide-Icons Eye und EyeOff tauschst du mit showIcon und hideIcon.

Sollte das Passwort beim Absenden wieder verborgen werden?

GOV.UK schaltet das Feld beim Absenden des Formulars zurück auf type="password". So merkt sich der Browser den Wert nicht als frühere Eingabe und schlägt ihn nicht in normalen Textfeldern vor. Die Wingo-Komponente macht das nicht von selbst. Steuer visible und verbirg das Passwort in deinem Submit-Handler. flushSync sorgt dafür, dass das Input wieder auf type="password" steht, bevor der Browser das Formular ausliest:

import { flushSync } from "react-dom"

<form onSubmit={() => flushSync(() => setVisible(false))}>
  <PasswordInput name="password" label="Passwort" visible={visible} onVisibleChange={setVisible} />
</form>

Wie funktioniert die Caps-Lock-Warnung?

KeyboardEvent.getModifierState("CapsLock") liefert den aktuellen Zustand, und dieselbe Methode gibt es auch auf Maus-Events. Lies ihn in keydown, keyup und mousedown, solange das Feld den Fokus hat, zeig eine Warnung an und blende sie bei blur aus. Die Wingo-Komponente hält unter dem Feld eine role="status"-Region bereit, damit die Warnung angesagt wird, sobald sie erscheint, und hängt sie an aria-describedby, solange sie sichtbar ist. Smartphones melden Caps Lock nicht, auf einem Touchscreen erscheint die Warnung also einfach nie. Schalte sie mit capsLockWarning={false} ab oder formulier sie mit capsLockLabel um.

Wie ergänze ich einen React Password Strength Meter?

Setz strength, und das Feld wird zum Registrierungsfeld: vier Balken, die sich beim Tippen füllen, ein Urteil in Worten daneben, eine Regel-Checkliste, die sich beim Fokus öffnet, und autocomplete="new-password". Mit generate kommt ein Zauberstab-Button dazu, der ein zufälliges Passwort einsetzt.

"use client"

import { useState } from "react"
import { PasswordInput, passwordRules } from "@/components/ui/password-input"

const rules = passwordRules({
  minLength: 10,
  labels: {
    length: (n) => `Mindestens ${n} Zeichen`,
    lower: "Ein Kleinbuchstabe",
    upper: "Ein Großbuchstabe",
    number: "Eine Ziffer",
    symbol: "Ein Sonderzeichen",
  },
})

export function NewPassword() {
  const [password, setPassword] = useState("")
  return (
    <PasswordInput
      name="password"
      label="Passwort"
      value={password}
      onValueChange={setPassword}
      strength
      rules={rules}
      showRules="focus"
      strengthLabels={["Zu schwach", "Schwach", "Okay", "Gut", "Stark"]}
      generate
      required
    />
  )
}

Ein paar Entscheidungen in diesem Code sind Absicht:

• Das Urteil ist Text, nicht nur Farbe. Rote, gelbe und grüne Balken sagen jemandem mit Farbenblindheit nichts. Das Label neben den Balken sagt „Schwach“ oder „Stark“.
• Die Balken sind für Screenreader verborgen. Das Urteil geht 500ms nach dem letzten Tastendruck an eine höfliche Live-Region. Wer einen Screenreader nutzt, hört also einmal „Password strength: Good“ statt einer neuen Ansage bei jeder Taste.
• Jede Regel sagt ihren Zustand an. Die Checkliste ist über aria-describedby mit dem Input verknüpft, solange sie offen ist, und jede Zeile endet mit einem visuell verborgenen „met“ oder „not met“ (ruleMetLabel, ruleUnmetLabel).
• Die Checkliste klappt bei blur nicht zu, solange Text im Feld steht. Sonst würde der Absende-Button darunter genau in dem Moment hochspringen, in dem der Daumen nach ihm greift.
• Der Generator nutzt crypto.getRandomValues mit Rejection Sampling, lässt leicht verwechselbare Zeichen weg (0, O, l, 1, I), garantiert ein Zeichen jeder Klasse und zeigt das Ergebnis an, bis der Fokus das Feld verlässt.

Reicht die eingebaute Passwortstärke-Anzeige?

Nicht für sich allein. Sie ist eine Orientierungshilfe. Das Standard-scorePassword gibt 0 für leere, kurze oder häufige Passwörter zurück, vergibt einen Punkt pro erfüllter Regel neben der Länge (bis zu 3) und einen weiteren ab 12 Zeichen und zieht einen ab bei Wiederholungen wie aaa oder Folgen wie 1234. Das fängt die offensichtlichen Fälle ab. Es weiß aber nicht, dass Summer2026! ein Muster ist, das Angreifer früh durchprobieren: Es enthält alle vier Zeichenklassen, also bewertet die Standardanzeige es als Good.

Wenn der Score über die Registrierung entscheidet, setz über die Prop score einen echten Schätzer ein. Mit zxcvbn-ts (opens in a new tab) (Setup geprüft am 5. November 2026):

import { ZxcvbnFactory } from "@zxcvbn-ts/core"
import * as common from "@zxcvbn-ts/language-common"
import * as en from "@zxcvbn-ts/language-en"

const zxcvbn = new ZxcvbnFactory({
  translations: en.translations,
  graphs: common.adjacencyGraphs,
  dictionary: { ...common.dictionary, ...en.dictionary },
})

export function SignUpPassword() {
  return <PasswordInput name="password" label="Passwort" strength score={(p) => zxcvbn.check(p).score} />
}

Die Wörterbücher sind groß, also lad das nur auf der Registrierungsseite.

Was sagen aktuelle Richtlinien zu Passwortregeln?

Sie setzen auf Länge und eine Sperrliste, nicht auf Zeichenmischungen. Der Text von NIST SP 800-63B (opens in a new tab) in Revision 4 (Abschnitt 3.1.1, geprüft am 5. November 2026) legt fest, dass Prüfstellen keine Zusammensetzungsregeln vorschreiben dürfen. Sie sollen mindestens 64 Zeichen zulassen und eine Option zum Anzeigen des Passworts anbieten, sie müssen Passwortmanager und Autofill erlauben, und sie sollen das Einfügen zulassen. Verlangt werden mindestens 15 Zeichen, wenn das Passwort der einzige Faktor ist, und 8, wenn es Teil einer Mehr-Faktor-Anmeldung ist. Außerdem müssen neue Passwörter mit einer Sperrliste häufiger, erwartbarer und kompromittierter Werte abgeglichen werden. In der Praxis heißt das:

• Behalte eine Längenregel und streich die Regeln für Großbuchstaben, Ziffern und Sonderzeichen: rules={passwordRules({ minLength: 15 }).filter((r) => r.id === "length")}. Nimm auch für die Anzeige einen echten Schätzer: Der Standard-Score vergibt einen Punkt pro Klassenregel in der Liste, mit nur der Längenregel kommt er also nie über 1 hinaus.
• Blockier nie das Einfügen und setz maxLength nie unter 64.
• Mach die Sperrlistenprüfung auf dem Server. Die Anzeige im Client gibt nur eine Empfehlung, die Entscheidung trifft der Server.

Worüber stolpert man sonst noch?

Über vier kleinere Dinge: ein Bestätigungsfeld, Icons von Passwortmanagern, Autofill und die Texte für Login-Fehler.

• Ein Feld zum Bestätigen des Passworts. Laut GOV.UK ist ein zweites Feld nicht nötig, weil man mit dem Anzeigen-Toggle prüfen kann, was man getippt hat. Wenn du trotzdem eins behältst, vergleich bei blur statt bei jedem Tastendruck und gib jedem Toggle ein eigenes Label.
• Icons von Passwortmanagern über deinem Auge. Manche Passwortmanager-Erweiterungen zeichnen ein eigenes Icon an den rechten Rand des Input-Elements. In der Wingo-Komponente sitzen Augen- und Zauberstab-Button außerhalb des nativen Inputs, das Icon landet also vor dem Toggle statt darauf.
• Die Anzeige flackert bei Autofill. Ein Passwortmanager kann das Feld füllen, bevor die Person es berührt. Bis das Feld den Fokus bekommt, bewertet die Komponente weiter den Startwert, ein automatisch ausgefülltes Passwort lässt die Balken beim Laden der Seite also nicht springen.
• Fehlertexte. Beim Login behältst du eine einzige allgemeine Fehlermeldung für falsche E-Mail oder falsches Passwort. Unser Guide zur shadcn Login Page erklärt die Gründe und den ganzen Ablauf.

Wo passt der Password Input in ein komplettes Registrierungsformular?

Er ist ein Feld in einem Block, der den Rest schon erledigt. Ein Passwortfeld ist ein Schritt in einem Formular, das außerdem eine E-Mail, einen Absende-Zustand und Fehler vom Server braucht. Der Block Register Page verbindet den Password Input mit react-hook-form und zod: Dieselben Regeln speisen die Checkliste und das Schema, Checkliste und Validierung widersprechen sich also nie, und ein Mindest-Score (standardmäßig 2, einstellbar über passwordMinScore) blockiert schwache Passwörter schon vor dem Absenden. Der Block Login Page nutzt die Login-Variante mit der Aktion „Passwort vergessen?“. Für den Rest des Formulars teilen sich die Komponenten Input und Field dieselbe Box, dieselben Größen und denselben Aufbau für Fehler, und unser Guide zu React-Formularkomponenten behandelt Labels, zod und mobile Tastaturen für alle davon. Weitere Komponenten-Guides findest du in der Kategorie Komponenten.

Nächster Schritt

Field und Input sind kostenlos. Der Password Input und der Block Register Page gehören zu Wingo UI Pro (Preise). Öffne die Doku zum Password Input, probier dort die sechs Beispiele aus (Regeln für die Registrierung, Caps Lock, Generator, Bestätigung, gesteuerte Sichtbarkeit, Größen) und installier ihn mit npx wingo-ui@latest add password-input, wenn er zu deinem Formular passt.

Häufige Fragen

Hat shadcn/ui eine Password-Input-Komponente?

Nein. Stand 5. November 2026 führt die Komponentenliste von shadcn/ui Input, Input Group und Field, aber keinen Password Input. Jeder shadcn Password Input, den du findest, ist also ein Community-Snippet oder eine Bibliothekskomponente auf Basis von Input.

Sollte der Button zum Passwort anzeigen tabIndex -1 haben?

Nein. Wer mit Tastatur oder Screenreader arbeitet, muss ihn erreichen. Lass ihn ein echter Button in der Tab-Reihenfolge mit einem aria-label und aria-pressed, die den aktuellen Zustand wiedergeben. Der Password Input von GOV.UK nutzt für seinen Anzeigen-Toggle ein natives button-Element, das von Haus aus fokussierbar ist.

Wie baue ich einen React Password Strength Meter?

Bewerte das Passwort von 0 bis 4, füll pro Punkt einen Balken und schreib das Urteil in Worten neben die Balken, damit die Farbe nicht das einzige Signal ist. Sag das Urteil über eine höfliche Live-Region an, sobald das Tippen stoppt, und nimm einen echten Schätzer wie zxcvbn-ts, wenn der Score über die Registrierung entscheidet.

Wie erkenne ich Caps Lock in einem Passwortfeld?

Ruf event.getModifierState("CapsLock") in Handlern für keydown, keyup und mousedown auf, solange das Feld den Fokus hat, und blende die Warnung bei blur aus. Smartphones melden den Caps-Lock-Zustand nicht, die Warnung erscheint also nur mit einer Hardware-Tastatur.

Sollte ein Registrierungsformular Großbuchstaben, Ziffern und Sonderzeichen erzwingen?

Nein. Laut NIST SP 800-63B Revision 4 dürfen Prüfstellen keine Zusammensetzungsregeln vorschreiben und müssen neue Passwörter mit einer Sperrliste häufiger und kompromittierter Werte abgleichen. Eine Längenregel, eine Sperrlistenprüfung auf dem Server und eine echte Stärkeschätzung folgen dieser Vorgabe besser als eine Checkliste mit fünf Regeln.