Decoding a JWT does not verify it. The first two segments are Base64URL text wrapped around JSON. Anyone can decode them without a key, which is why a decoder can show a header and a payload immediately. Verification is a different act: recompute the signature over those segments with a key you already trust, and compare. A page that only decodes has not done that, even when the third segment is present and the JSON looks tidy.
The JWT Decoder Tool on YallaSolve splits the token on dots, Base64URL-decodes the header and the payload, and parses both as JSON. It reports whether a signature segment is present or empty. The status says verification was not performed. There is no secret field and no control that says verify. The signature is not printed again as if it had been checked.
A JWT that this decoder can inspect has three segments separated by dots. The first is the header. The second is the payload. The third is the signature. The header and payload are JSON once they are decoded. A typical header names alg and typ. The payload is a set of claims: whatever the issuer put there. The signature is not JSON. The decoder does not parse it and does not display it as a result.
The segments use Base64URL, not the standard alphabet with +, /, and required padding. Base64URL uses - and _. That alphabet is also what the Base64 Encoder / Decoder calls URL-safe, for ordinary text. A JWT is not one Base64 string with dots left in it. Pasting a whole token into the text page does not split header, payload, and signature. Use the decoder for the token. Use the text page when you are holding a single Base64 string and you need the alphabet.
The third segment can be long, short, or empty. Present means the token had a third piece after the second dot. It does not mean the piece matches the header and payload. Someone can keep a real-looking third segment, replace the payload, or move a signature from another token. Decode will still show JSON if the first two segments are well-formed Base64URL and the JSON parses. The tool is doing what it was built to do. It is not catching the swap.
Checking the signature means taking the signing input, applying an algorithm the verifier has already chosen, using a secret or a public key the verifier holds, and comparing the result to the third segment. The algorithm has to be one the verifier accepts. This article does not walk through that computation, and the YallaSolve page does not implement it. A secret box on a decode page would turn local inspection into a place where keys get pasted. The page does not have that field.
exp, nbf, iat, iss, and aud are fields in the payload when the issuer wrote them. Decode shows the numbers and strings. It does not read a clock, compare an issuer, or check an audience. A payload whose exp is in the past still decodes. A payload with no exp still decodes. Neither result is an expiry decision.
alg is a field in the header the token itself supplied. Reading a value such as none or HS256 is not a decision to trust that name. A decoder that lets the token pick the verification algorithm, including an algorithm that means no signature, is a known way to accept a forged token. YallaSolve does not pick an algorithm from the header, because it does not verify. Seeing alg in the JSON is information. It is not a pass.
A token can fail this page for a structural reason: not three segments, a header or payload that is not valid Base64URL, or JSON that does not parse. Those errors mean the text is not a JWT this decoder can show. They do not mean a verifier would have rejected a signature, and a clean decode does not mean a verifier would have accepted one. Empty input is an empty box. Clearing the form removes the token from the page. The paste is treated as sensitive because a payload can carry identifiers. The page does not send it anywhere and does not write it to storage. The input cap is 32,768 characters.
Use a decoder to read what a token says. Use a verifier that already has the right key, and that does not let the token choose its own rules, when you need to accept the token. Decoding a JWT does not verify it, does not prove the claims, and does not make the third segment trustworthy. On YallaSolve the decoder stops at the JSON and says so.
No. Base64URL decoding does not use a key. The JSON is visible because the payload was not encrypted by the format itself.
No. The page only reports that the segment is present or empty. It does not compare it to anything.
No. They are shown as JSON fields. The page does not compare them to a clock or to an expected issuer.
No. There is no secret field and no verify control. Do not add a key to the token box.
The YallaSolve decoder stays in this browser, and Clear removes the token from the page. A payload can still be sensitive. Do not paste a token you cannot afford to have on screen.