Alle Werkzeuge im Detail

Bilder werden über ein <canvas>-Element neu gezeichnet: Die Datei wird per createImageBitmap (oder FileReader als Fallback) eingelesen, auf das Zielformat gezeichnet und per canvas.toBlob() als PNG, JPG oder WebP neu kodiert — dafür reicht die eingebaute Bild-Engine des Browsers. Für ICO wird das Bild in mehreren Auflösungen auf eigene Canvases gezeichnet, jede als PNG kodiert, und die Ergebnisse werden von Hand zu einem gültigen Mehrfach-Icon-Container zusammengesetzt (ICONDIR-Header plus ein Verzeichniseintrag pro Auflösung, Byte für Byte über die DataView-API geschrieben). BMP wird komplett selbst erzeugt: Aus den rohen Pixeldaten (ImageData) baut das Werkzeug eine unkomprimierte BITMAPFILEHEADER/BITMAPINFOHEADER-Struktur nach der offiziellen Windows-Bitmap-Spezifikation. Beim Sammel-Download mehrerer Dateien kommt ein selbst geschriebener ZIP-Writer zum Einsatz, der für jede Datei eine CRC32-Prüfsumme berechnet und lokale Dateiheader plus zentrales Verzeichnis nach dem ZIP-Format zusammensetzt (unkomprimiert, „Stored"-Methode) — ganz ohne externe Bibliothek.

Die Datei wird per Web-Audio-API dekodiert (AudioContext.decodeAudioData) und liegt danach als rohe PCM-Samples im Speicher vor. Für die Wellenformanzeige werden die Samples auf die Canvas-Breite heruntergemittelt (ein Peak-Wert pro Pixel-Spalte). Der gewählte Ausschnitt läuft anschließend durch einen OfflineAudioContext, der ihn auf die Zielabtastrate resampelt. Für MP3 werden die PCM-Daten danach Frame für Frame an lamejs übergeben, eine im Browser laufende JavaScript-Portierung des LAME-Encoders (LGPL-lizenziert, lokal eingebunden, keine Serveranfrage nötig). Für WAV schreibt das Werkzeug stattdessen von Hand einen RIFF/WAVE-Container mit PCM-Header nach der Microsoft-WAVE-Spezifikation. Beides läuft synchron im Hauptthread des Browsers, ganz ohne Upload.

Die eigentliche QR-Matrix berechnet die Bibliothek qrcode-generator nach dem offiziellen QR-Code-Standard, inklusive Reed-Solomon-Fehlerkorrektur in wählbarer Stufe (L/M/Q/H — je höher, desto mehr Module können beschädigt sein und der Code bleibt trotzdem lesbar). Aus der berechneten Modul-Anzahl zeichnet das Werkzeug das Ergebnis selbst: für PNG auf ein <canvas> (Export per toBlob), für SVG durch direktes Zusammensetzen von <rect>-Elementen zu einem Vektor-Bild, das beim Skalieren beliebig scharf bleibt. WLAN-, Kontakt-, E-Mail- und SMS-Eingaben werden vor der Kodierung nach den jeweils zugehörigen Standard-Formaten zusammengesetzt (z. B. „WIFI:T:WPA;S:…;P:…;;" für WLAN oder vCard/MECARD-Syntax für Kontakte).

Ping wird über mehrere kurze Anfragen mit 0 Byte Nutzlast gemessen; die reine Serververarbeitungszeit wird dabei über den server-timing-Antwort-Header herausgerechnet, sodass nur die tatsächliche Netzlaufzeit übrig bleibt (die erste Anfrage wird verworfen, da sie durch den Verbindungsaufbau verfälscht wäre). Für Download und Upload laufen mehrere parallele Datenströme (4 beim Download, 3 beim Upload) gegen stufenweise größer werdende Testblöcke; die übertragenen Bytes werden alle 100 ms abgetastet — beim Download über den Reader eines ReadableStream, beim Upload über XMLHttpRequest-Fortschrittsereignisse — und daraus eine gleitende Mbit/s-Rate berechnet, wobei die ersten rund 25 % als Aufwärmphase aus dem Endergebnis herausgerechnet werden. Standort, Netzbetreiber (AS) und Testserver stammen von einem eigenen JSON-Endpunkt (speed.cloudflare.com/meta), da diese Angaben nicht mehr über Antwort-Header der Messungen selbst mitgeliefert werden. Tacho, Ringe und das Sternenfeld im Hintergrund sind eine reine Canvas-2D-Animation, komplett unabhängig von der eigentlichen Messung.

Alle Angaben stammen aus Standard-Browser-APIs, die ganz ohne besondere Rechte auslesbar sind: Bildschirm über screen.width/height und window.devicePixelRatio, Prozessorkerne über navigator.hardwareConcurrency, Akkustatus über die Battery Status API (navigator.getBattery(), von Firefox und Safari aus Datenschutzgründen nicht angeboten) und Netzwerktyp über die Network Information API (navigator.connection). Die Grafikkarte wird über einen WebGL-Kontext ausgelesen: Ein unsichtbares <canvas> erzeugt einen WebGL-Kontext, dessen Erweiterung WEBGL_debug_renderer_info den tatsächlichen Grafiktreiber-/GPU-Namen zurückliefert, den der Browser sonst aus Fingerprinting-Gründen verschleiert. Alle übrigen „Funktionen" werden per Feature-Detection geprüft — also durch einfache typeof- bzw. Existenz-Abfragen der jeweiligen API im window- oder navigator-Objekt, ohne sie tatsächlich auszuführen.

Zufallspasswörter nutzen crypto.getRandomValues() — den kryptografisch sicheren Zufallsgenerator des Browsers — mit Rejection Sampling: Statt einfachem Modulo wird bei zu großen Zufallswerten neu gewürfelt, damit kein Zeichen durch Modulo-Bias leicht bevorzugt wird. Passphrasen ziehen zufällige Wörter aus einer festen, gut tippbaren deutschen Wortliste. Die Stärke-Schätzung berechnet die Bit-Entropie aus genutzter Zeichenmenge und Länge und zieht Punkte für erkannte Schwachmuster ab (Tastatur-Folgen wie „qwertz", Wiederholungen, Jahreszahlen, Treffer in einer Liste bekannter Passwörter). Die Datenleck-Prüfung berechnet lokal per Web-Crypto-API einen SHA-1-Hash und schickt nur dessen erste 5 Hex-Zeichen an die Have-I-Been-Pwned-Schnittstelle; die Antwort enthält alle bekannten Hashes mit diesem Präfix, sodass der eigentliche Abgleich mit dem Rest des Hashs erst lokal im Browser passiert (k-Anonymitätsverfahren) — das vollständige Passwort verlässt zu keinem Zeitpunkt den Browser.

Alle Auswertungen laufen mit regulären Ausdrücken direkt im Browser: Wörter werden per Wortgrenzen-Regex gezählt, Sätze anhand von Satzzeichen (. ! ? …) getrennt, Absätze anhand von Leerzeilen. Die Base64-Kodierung kombiniert die eingebauten btoa()/atob()-Funktionen mit der TextEncoder/TextDecoder-API, damit auch Umlaute und Emojis korrekt kodiert werden — reines btoa() versteht nämlich nur Latin-1-Zeichen. Suchen & Ersetzen mit aktivierter Regex-Option übergibt das eingegebene Muster direkt an die JavaScript-eigene RegExp-Engine.

Die Umrechnung zwischen HEX, RGB, HSL, HSV und CMYK läuft über die jeweiligen mathematischen Standard-Formeln direkt in JavaScript, ohne Rundung durch externe Bibliotheken. Der Kontrast-Prüfer berechnet die relative Leuchtdichte beider Farben nach der offiziellen WCAG-2-Formel (0,2126·R + 0,7152·G + 0,0722·B nach Gamma-Korrektur der Kanäle) und daraus das Kontrastverhältnis — genau die Formel, die auch Prüf-Tools wie Lighthouse verwenden, daher stimmen die AA-/AAA-Bewertungen exakt mit dem Standard überein. Die Farbpipette nutzt, sofern vorhanden, die native EyeDropper-API des Browsers, um Farben von beliebiger Stelle des Bildschirms aufzunehmen. Paletten entstehen durch Drehung im HSL-Farbraum (feste Winkel je nach Schema, z. B. 180° für Komplementär oder 30°-Schritte für Analog) beziehungsweise durch gezieltes Abdunkeln oder Aufhellen der Helligkeit für Schattierungen und Tönungen.

Jede Kategorie rechnet über eine gemeinsame Basiseinheit um (z. B. Meter für Länge, Kilogramm für Gewicht, Kelvin für Temperatur): Der Eingabewert wird zuerst in diese Basiseinheit umgerechnet und von dort in die Zieleinheit zurück — so genügt pro Einheit nur ein einziger Umrechnungsfaktor statt einer eigenen Formel für jedes mögliche Einheitenpaar. Temperatur ist dabei eine Ausnahme, da sie keine reine Multiplikation, sondern eine affine Umrechnung braucht (z. B. °C → K durch Addition von 273,15) — deshalb hat jede Temperatur-Einheit eigene Umrechnungsfunktionen statt eines einzelnen Faktors.