Parse and validate otpauth:// URIs used by authenticator apps to extract TOTP/HOTP configuration parameters.
An otpauth URI is the text normally carried inside an authenticator enrollment QR code. This parser separates the otpauth scheme, TOTP or HOTP mode, label, shared secret, issuer, and mode-specific query parameters, then flags malformed or incomplete configurations. Percent-encoded label characters are decoded so an account such as alice%40example.com can be inspected as [email protected]. The shared secret is key material, not the temporary numeric code shown by an authenticator. Because exposing that secret compromises the enrollment, parsing occurs in the browser and the URI is not uploaded.
A concrete input and expected output from the current implementation.
Input
otpauth://totp/Example:alice%40example.com?secret=JBSWY3DPEHPK3PXP&issuer=Example&algorithm=SHA1&digits=6&period=30
Expected output
Valid TOTP configuration; type: totp; label: Example:[email protected]; issuer: Example; secret: JBSWY3DPEHPK3PXP; algorithm: SHA1; digits: 6; period: 30 seconds
The URI selects TOTP, and the path label decodes alice%40example.com to [email protected]. The remaining values come directly from the query parameters: period 30 specifies a 30-second time step, and digits 6 specifies six-digit codes.
The expected shape is otpauth://TYPE/LABEL followed by query parameters. TYPE distinguishes time-based TOTP from counter-based HOTP. The path label identifies the account and may begin with an issuer prefix separated by a colon. Query parameters carry the Base32 secret and metadata such as issuer, algorithm, digit count, TOTP period, or HOTP counter. The parser presents these components separately after URI decoding.
A usable configuration needs a recognized OTP type, a label, and a secret. HOTP additionally needs an initial counter, while TOTP can carry a time-step period. Values such as digits, period, and counter are numeric configuration fields, not generated passwords. Parsing does not contact the service named by the issuer or prove that the server enrolled the same secret.
No. It extracts and validates provisioning configuration. Producing a TOTP code also requires applying the configured algorithm and digit count to the current time step. HOTP instead requires the correct moving counter. This tool inspects the URI fields; it does not establish whether a displayed code matches the state held by a server.
The path label may contain a provider prefix and an account name separated by a colon, while the issuer query parameter explicitly names the provider. Authenticator applications use this information when displaying and grouping credentials. When both issuer representations are present, they should agree. The parser can expose a mismatch, but it cannot determine which name the provisioning service intended.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Generate strong, random passwords with customizable length, character sets, and complexity requirements.
Analyze password strength with entropy scoring, crack-time estimates, and improvement suggestions.
Create cryptographically random strings for API keys, tokens, salts, and unique identifiers.
Create QR codes for URLs, text, Wi-Fi credentials, vCards, and more with customizable size and colors.
Scan and decode QR codes from uploaded images or your device camera to extract embedded data.
Compute MD5, SHA-1, SHA-256, and SHA-512 checksums to verify file integrity and detect tampering.