It probably goes without saying, but I would like a dark theme as well.

On paste, will be great if it can auto-remove Bearer prefix.

These are great suggestions.

A visual indicator showing the time left before jwt expired could be helpful

My only real nitpick/gripe is how large the hero is (the part with JSON Web Tokens are an open...). It adds an extra step to what would be a keyboard only process:

1. Ctrl+L
2. j w t Enter
3. scroll the text input into view then click inside it to re-focus
   • ^ this part here
4. Ctrl+V

It also makes it slightly more difficult to align the outputs of 2 different tabs for a quick visual diff. Without the hero I could scroll both tabs to the top and their outputs would be perfectly aligned.

Love the tool and the work you've put into it. Was worried this was gonna be one of those announcements that get 800 thumbs down, but was presently surprised instead.

On paste, will be great if it can auto-remove Bearer prefix.

In the same vein it would be nice to strip Authorization and any other non-JWT header components so one could copy/paste an entire raw header line like Authorization: Bearer eyJ.... Would minimize the effort required to select and copy a huge header line using clunky tiny dev tool windows.

This is more of a nice to have and perhaps a bit too much. The Bearer thing alone would be fantastic because I run into that exact thing just about every day.

My spontaneous reaction with the screenshots of the decoding part is that they don't feel compact enough. I really enjoy the current two column layout where you can easily have everything in view without scrolling for a lot of JWT:s.

For example I think the "DECODED HEADER" and "DECODED PAYLOAD" headers could live in the tab-bar (JSON/claims breakdown) with those tabs off to the right side (with a separator between them and the copy button) or even moved atop all of it to control both header and payload. Then the two boxes could stick together. with probably something similar for the signature section.

The full width layout seems like it'd be great on phones and narrow screens, but for larger screens the current two column mode is better imo. I understand the full width makes the claims breakdown with a third column for the description easier, but here too I only think that makes sense on small screens, on a laptp or desktop the compactness is much more valuable and the hover tooltips work fine

Looks really nice! Maybe one minour suggestion would be to add the "relative time" to the unix timestamp decoding tooltip, so it also showed something like "in an hour", for example.

Being able to capture the paste anywhere on the page as opposed to needing to focus the JWT field would be nice.

Thank you every one for your suggestions thus far! 🙏 I appreciate the level of detail on your feedback. Keep it coming. These are nice UI/UX boosters.

It also makes it slightly more difficult to align the outputs of 2 different tabs for a quick visual diff. Without the hero I could scroll both tabs to the top and their outputs would be perfectly aligned.

@ParkerM You may like the new sub-navigation 👀

The page loads:

You can tab into the desired navigation and sub-navigation item (I plan to use React Aria to make this nice) and press Enter:

Now, you'll quickly have the section you need "pinned" to just below the navbars and you'll have consistent UI across tabs for that visual comparison.

What do you think?

@swantzter Do you find yourself using both the decoding and encoding features simultaneously side by side? If not, would it help your UX if you had an option to stack the "Decoder" and "Encoder" side-to-side using "tabs"?

My reasoning behind putting everything on the same page by default is that it will help search engine bots index the site and help more people find this tool for decoding/encoding :) But, I am thinking, that you could have an option to switch to a tabs layout for the two major tools.

And then, what if we give you a "compact" mode for the "Decoder" similar to how the new "Encoder" looks? "Compact encoding" could default to presenting the decoding output as JSON. The new "Claims Breakdown" is helpful for people who are just starting to learn about JWTs as they can benefit from that greater level of detail; while someone who uses the tool routinely can benefit from something less detailed and more compact. 🤔

@swantzter This is what the compact mode could look like 🤔 I just prototyped this 😄 In compact mode, we'd also yeet the hero, helper text, and also the "alg" input which we use for examples.

(In this prototype, you'd still need to scroll down to get to the Encoder widget, but we could make that a side-to-side tab)

Do you find yourself using both the decoding and encoding features simultaneously side by side? If not, would it help your UX if you had an option to stack the "Decoder" and "Encoder" side-to-side using "tabs"?

@DanOnCall sorry I was unclear, I'm in full support of having the encoder and decoder be separate tools and have them on different "pages". However now that you mention it something that would be nice is to have the decoded info carry over to the encoder when you switch tool since a fairly common usecase for me is "paste a token, edit a couple values, add the secret, copy the modified token).
For the "compact" decoder you could even have a pretend three column layout and add a swiping animation if you want to be fancy about it:

+-border is the viewport
+++++++++++++++++++++++++++++++++++++++++
+ [Slected Tab: Decode], [Tab: Encode]  +
+                                       +
+ | Column 1        | Column 2         |+ Column 3
+ | Paste JWT token | Header/Body/sign |+ Encoded JWT
+ | editable        | readonly         |+ readonly
+ | visible         | visible          |+ Hidden
+++++++++++++++++++++++++++++++++++++++++

hen when you switch tab to encode the three columns "move" to the left, making column 1 invisible and column 3 visible

+-border is the viewport
                     +++++++++++++++++++++++++++++++++++++++++
                     + [Slected Tab: Decode], [Tab: Encode]  +
                     +                                       +
  | Column 1        |+ Column 2         |+ Column 3          +
  | Paste JWT token |+ Header/Body/sign |+ Encoded JWT       +
  | readonly        |+ editable         |+ readonly          +
  | hidden |        |+ visible          |+ visible            +
                     +++++++++++++++++++++++++++++++++++++++++

And then, what if we give you a "compact" mode for the "Decoder" similar to how the new "Encoder" looks? "Compact encoding" could default to presenting the decoding output as JSON. The new "Claims Breakdown" is helpful for people who are just starting to learn about JWTs as they can benefit from that greater level of detail; while someone who uses the tool routinely can benefit from something less detailed and more compact. 🤔

Yeah, I agree the claims details are useful for more unfamiliar users and I think the concept is really good. But like you say, for someone using the tool often the compact mode imo is more practical. Two notes for this: a) what mode you've selected needs to be saved with localStorage/cookies, b) you should be able to set the mode using query parameters, so you can bookmark for example https://jwt.io/decode?mode=compact and have that bookmark sync across your browsers, so you don't have to change the setting manually on every new computer

@DanOnCall I like your mockup of the compact mode, but what I was really getting to in my original message was that I think the compact mode should be even more compact. I don't have all your components on hand so I tried to rearrange your mockup in an image editor:

Edit: I'm imagining the JWT input field expands in height with the header and payload outputs so that the secret and signature verification are always vertically aligned

Any plans on updating the libraries page? Please add a Search input instead of the current filter by.

Also, the requirement of the jwt secret key could be added as it would make the decoding of the jwt a bit more secure so that any jwt token decoding needs to provide a secret that was used to encode that token. Isn't decoding jwt tokens can be done using Buffer module in nodejs ?

A frequent usecase for me is to copy a jwt, paste it, inspect, make a change, add the correct secret and copy the new jwt token to use elsewhere. Would it still be possible?

asdasd

It will be nice to use jwt.io in getting in-depth information on the token.

It will be helpful to learn what claims are commonly used, and what claims are specific to other popular idPs.

It will be nice to use jwt.io in getting in-depth information on the token.

It will be helpful to learn what claims are commonly used, and what claims are specific to other popular idPs.

In the same vein, it would be neat if the tool showed human-friendly values for more claims. I find myself instinctively mousing over non-standard claims that look like unix timestamps because I expect the helpful tooltip to show me the parsed datetime, but it only appears for standard claims like exp and iat.

If the tool supported nonstandard claim awareness, it could simply include type information in the metadata for those claims (this is presumably how it knows exp is a unix timestamp and can be represented differently). Otherwise I guess claims' "types" could be inferred by patterns or other heuristics, but perhaps that would be excessively complex or undesirable.

I'm loving that "Clear" button in the mockups! Have you ever tried to use jwt.io on a mobile device? It's unbelieveably painful to manually delete the sample jwt token before i can paste in the one i want to decode.

Thank you, everyone, for all the feedback and validation that y'all have provided. We'll be working with our designers to iterate on this feedback and triage on what we can include. One of my commitments is to keep investing time and resources on the site to keep it up to date and expand it. Long-term, I want to bring support for JWE too!

I'll see if I can get y'all exclusive access to the MVP 👑 so that y'all can play with it and see how it feels. We'll be back into the development / design saddle after DevDay 24, so it would be around late Oct/Nov. Can't wait!

I would love for the Chrome Extension to make a reappearance.

https://auth0.com/blog/amp/announcing-our-chrome-jwt-extension/

Having the UX of jwt.io in the Developer Tools is super nice, especially if there is configuration (mostly for development) associated with the site.

One flow that I use occasionally which would be a shame to lose is

1. Decode an existing JWT
2. Edit the decoded claims
3. Use the re-encoded edited JWT

This is definitely an edge case but it is occasionally handy with the current flow and I can't see how it would be (as) easily accomplished with the three separate tools.

As I read the proposal, the decode tool would allow you to copy each decoded segment, but then you'd have to copy two seperate segments to get them from the decoder to the encoder.

It would be nice if there was an easy way to get the whole decoded JWT into the encoder for further editing

Regarding the future of JWT.io
.io TLD future is unclear: https://every.to/p/the-disappearance-of-an-internet-domain

May be it worth looking into changing it? jwt.tech?

@orthanc We have been thinking a lot about that use case. A two-way communication flow between decoder and encoder is definitely possible -- and desirable.

@nicc777 "Dark theme" as a feature got the most reactions here and I am happy to share that we have done great progress on that. Our work with the Passkeys Playground (https://learnpasskeys.io/) helped a lot.

Lights out:

Lights in:

I want to share a "private beta" preview with y'all within the next weeks!

@DanOnCall Awesome - thanks!

@nicc777 "Dark theme" as a feature got the most reactions here and I am happy to share that we have done great progress on that. Our work with the Passkeys Playground (https://learnpasskeys.io/) helped a lot.

Lights out:

Lights in:

I want to share a "private beta" preview with y'all within the next weeks!

If allowed to present reviews,
I'd like to say that the UI could be enhanced more.

1. By removing the gradient effect in the middle card in both dark and light UI.
2. Just show Valid JWT or Invalid JWT. No need for the Ok or Not Ok statements
3. If possible can keep the entire JWT related information in viewport.

@shvamabps Thanks for your feedback. That's pretty good insight. What do you think of this approach that is more compact and information dense?

My vision is that you'll be able to collapse the info and warning boxes to make it more compact. We'll set a cookie with your preference so next time you visit, those will stay collapsed, giving you major focus into the debugger tool.

My vision is that you'll be able to collapse the info and warning boxes to make it more compact. We'll set a cookie with your preference so next time you visit, those will stay collapsed, giving you major focus into the debugger tool.

These are some amazing refractors that you have made. I think they need to the closable ones, probably that might be a good way to show the information. And as for the cookie part one can use that but I think that would make the alerts or warnings go off permanently which I think would make an issue when the JWT is invalid or incorrect.