01
Den tatsächlichen Request-Body verwenden
JSON nicht neu formatieren oder sortieren. Leerzeichen, abschließende Zeilenumbrüche und Unicode-Darstellungen können die signierten Bytes verändern.
- Für exakte Binärdaten Hex oder Base64 verwenden.
Hash & Crypto Helpers
HMAC-GeneratorNachricht und Schlüssel bytegenau prüfen
Kodierungen getrennt wählen, dann einen HMAC berechnen oder eine vorhandene Signatur prüfen.
HMAC-Generator
Nachricht
HMAC-Digest
Nachricht und Schlüssel bleiben im Seitenspeicher; kein Upload und keine Speicherung im Browser-Speicher.
Optionen
Kein Trimmen oder Normalisieren. Mehrzeilige Schlüssel als Hex/Base64; vollständige Referenz ohne Header-Präfix.
Nachricht: 1.000.000 UTF-16-Einheiten und Bytes. Schlüssel: 4.096 UTF-16-Einheiten, nicht leer.
Schlüssel eingeben und erzeugen oder prüfen. Die Nachricht darf leer sein.
Der HMAC-Generator hilft, wenn eine Webhook-Signatur trotz scheinbar gleicher Nachricht abweicht. Entscheidend sind die tatsächlich signierten Bytes und die Darstellung des Schlüssels.
Der HMAC-SHA256-Rechner startet mit SHA-256; SHA-512 und SHA-1 stehen ebenfalls bereit. Ein geheimer Schlüssel gehört zur HMAC-Berechnung. Ein einfacher Hash mit vorangestelltem Salt ist etwas anderes.
Warum diesen HMAC-Generator nutzen?
Schlüsseltext ist nicht automatisch Hex
Der HMAC-Generator dekodiert Nachricht und Schlüssel unabhängig. Als Text besteht 6162 aus vier Bytes, als Hex aus zwei. So lässt sich eine häufige Ursache unterschiedlicher Ergebnisse gezielt überprüfen.
Prüfen ohne vorheriges Erzeugen
Mit einem Referenzwert lässt sich die aktuelle Nachricht direkt prüfen. Ungültige Kodierung, falsche Länge und eine gültige, aber abweichende Signatur werden getrennt behandelt.
Signierte Bytes zuerst abgleichen
02
Schlüssel separat dekodieren
UTF-8 bedeutet wörtlicher Text, Hex bedeutet Bytepaare, Base64 bedeutet eine kodierte Bytefolge. Das Schlüsselfeld ist zunächst verdeckt.
- Einfügen und Ablegen von Schlüsseln mit Zeilenumbrüchen wird abgelehnt; der bisherige Schlüssel bleibt erhalten. Mehrzeilige Schlüssel zuerst als Hex oder Base64 kodieren.
03
Referenzformat festlegen
Ausgabe und Referenz können verschiedene Kodierungen verwenden. Erzeugen und Prüfen laufen manuell; geänderte Eingaben sperren das Kopieren alter Ergebnisse.
- Strg/Cmd + Enter prüft im Referenzfeld und erzeugt sonst einen HMAC. Während einer Berechnung startet die Tastenkombination keinen weiteren Vorgang.
Bedingungen der Signatur bestimmen
Drei vollständige Digest-Längen
SHA-256 liefert 32 Bytes, SHA-512 64 und SHA-1 20. Der Algorithmus muss zum Protokoll passen. SHA-1 bleibt für die Kompatibilität mit vorhandenen Systemen verfügbar.
Kodierungen unabhängig auswählen
Nachricht und Schlüssel unterstützen UTF-8, Hex und Standard-Base64. Ausgabe und Referenz unterstützen Hex und Base64. Bei Hex spielt Großschreibung keine Rolle, bei Base64 dagegen schon.
Native HMAC-Prüfung
Web Crypto erzeugt und prüft den HMAC. Eine Übereinstimmung bezieht sich auf die eingegebenen Bytes und den Schlüssel. Zeitstempel, Ablaufzeiten und Schutz vor wiederholten Anfragen werden nicht geprüft.
Eingaberegeln und Grenzen
- Keine stillen Korrekturen
- Kein Trimmen, keine Unicode-Normalisierung und keine JSON-Neusortierung. Hex benötigt vollständige Bytepaare ohne Präfixe oder Leerraum. Base64URL, Leerraum, falsches Padding und nichtkanonische Restbits werden abgelehnt; korrekt weggelassenes Padding ist erlaubt.
- Leere Nachricht erlaubt
- Der dekodierte Schlüssel darf nicht leer sein. Nachrichten sind auf 1.000.000 UTF-16-Einheiten und dekodiert 1.000.000 Bytes begrenzt, Schlüsseleingaben auf 4.096 UTF-16-Einheiten. Ungepaarte Surrogate sind ungültig.
- Nur vollständige Referenzen
- Die Referenz muss je nach Algorithmus 20, 32 oder 64 Bytes ergeben. Präfixe wie sha256= selbst entfernen. Gekürzte MACs, automatische Algorithmuserkennung, Dateien, URL-Abrufe und anbieterspezifische Vorlagen sind nicht vorgesehen.
- Ersetzen mit Vorschau
- Beispiel und Leeren zeigen vor dem Anwenden die ersetzten Zeichenmengen. Ein Rückgängig-Schritt stellt Eingaben, Optionen und Ergebnis wieder her. Der vorherige Schlüssel bleibt dafür im Seitenspeicher bis zur nächsten Eingabeänderung. Schlüsselverwaltung und Passwortspeicherung gehören nicht zum Werkzeug.
Fragen zum HMAC-Generator
Welchen Algorithmus soll ich wählen?
Den Algorithmus aus der Schnittstellendokumentation verwenden. SHA-256 ist voreingestellt. SHA-512 und SHA-1 dienen den jeweiligen Protokollen; der Wechsel verändert die notwendige Länge der vollständigen Referenz.
Wie prüfe ich mit diesem Tool eine Webhook-Signatur?
Den originalen Body und den geheimen Schlüssel verwenden und die Signatur aus dem Header extrahieren. Die vom Anbieter vorgeschriebene Zeichenfolge muss bereits vorbereitet sein. Dieses Werkzeug ergänzt keine Zeitstempel und prüft keine Gültigkeitsfrist.
Wird mein Schlüssel gespeichert?
Der HMAC-Generator sendet den Schlüssel nicht an einen Server und schreibt ihn nicht in den Browser-Speicher. Beim Leeren bleibt eine Rückgängig-Kopie im Seitenspeicher, bis erneut bearbeitet oder die Seite verlassen wird. Eine sichere physische Speicherlöschung kann JavaScript nicht garantieren.
Base64 oder Hex?
Beide stellen dieselben Digest-Bytes dar. Das Format der Referenz muss richtig gewählt sein. Ein SHA-256-Digest hat 64 Hex-Zeichen oder 44 Base64-Zeichen mit Padding. Die Ausgabe darf unabhängig davon anders kodiert sein.
Meine Ausgabe stimmt nicht. Was sollte ich prüfen?
Rohdaten, Schlüssel-Kodierung, Algorithmus und gegebenenfalls die vom Anbieter definierte Zeichenfolge vergleichen. Schon ein zusätzlicher Zeilenumbruch ändert das Ergebnis. JSON mit gleichem Inhalt kann unterschiedlich serialisiert sein.
Noch eine Frage?
Mit einer Referenz beginnen
Mit dem HMAC-Generator das RFC-Beispiel prüfen, ein Nachrichtenzeichen ändern und die Abweichung nachvollziehen.
Kodierungen getrennt wählen, dann einen HMAC berechnen oder eine vorhandene Signatur prüfen.