Stop Hardcoding Tokens. Generate Them Properly.
When you're building on Next.js with Better Auth, your API needs JWT support - and you need a way to test it before wiring everything up.
"Just paste a token from the browser" is the most common advice and the worst habit you can build.
Anyone who's shipped a Next.js app with Better Auth knows the setup is clean. Authentication is handled, sessions work, and your routes are protected. But the moment you start writing actual API endpoints that need to verify JWTs independently or when you need to hand off a token to another service; you hit a wall.
You need a token. A real, properly signed one. Not from a browser session you copied into Postman twenty minutes ago, and not a hardcoded string you put in a test file. You need something you generated yourself, with a payload you control, signed with a key that matches what your app expects.
That's what getJwt is for.
The problem it solves
Better Auth uses asymmetric key signing under the hood. Your app trusts tokens signed with a specific private key, and verifies them using the corresponding public key. During development and API testing, you often need to:
Create tokens with custom payloads
Verify a token's signature is valid
Expose the public key for consumers
Test without a running auth session
Doing any of this manually, every time, is tedious. Most developers end up with a loose script somewhere, or they skip testing the token logic entirely and trust it will work in production. Neither is great.
JWT signature verification is a trust boundary. If your API doesn't correctly verify tokens before acting on them, a malformed or forged token becomes a real security risk. Testing this properly before deployment is not optional.
How getJwt fits into your workflow
Think of getJwt as a local JWT workbench. You run it alongside your Next.js project during development, and it gives you three things:
Token generation with your own payload: You define what goes inside the token - the user id, roles, expiry, whatever your API expects. The tool signs it with the correct key and hands you a token you can immediately use in your API requests.
Signature verification: You paste in a token from getJwt or from anywhere else and it tells you whether the signature is valid against the key. No guessing, no "it should work," just a clear answer before you push code.
Public key exposure: The public key is surfaced directly from the tool. If another service needs to verify tokens issued by your app - a microservice, a webhook handler, a third-party integration, you can hand it the key immediately without digging through config files.
When you'd actually reach for this
The use case is very specific, and it's exactly the kind of thing that feels painful when there's no tool for it. You're building an API route in Next.js. It receives requests, checks the JWT in the Authorization header, and acts on the payload. You want to test it with curl, Postman, or a script; not through a logged-in browser session.
Without getJwt, you either intercept a real token from an active session (fragile, time-limited, tied to a real user), or you skip the auth check in the test environment (dangerous habit). With getJwt, you generate a valid token in seconds, drop it into your Authorization header, and test your route properly.
Real scenario
You're writing a protected API endpoint that checks for an admin role in the JWT payload. With getJwt, you generate one token with role: "admin" and one without and test both cases before the feature ships.
Not a production tool, and that's the point
It's worth being clear: getJwt is a developer tool. It's for the gap between "I understand the auth flow conceptually" and "my API is correctly verifying signatures in a real request." It lives in your development environment, not in your deployed app.
The value is that it makes the testing of JWT-protected APIs feel natural and repeatable. No more one-off scripts. No more copying tokens from the browser. Just a clean tool that does one thing well.
Getting started
If you're already working with Next.js and Better Auth, adding getJwt to your local setup is a small lift with a noticeable improvement in how you develop and test API routes. Check the repository for setup instructions, it's straightforward to point at your existing keys and start generating tokens right away.
The moment you run your first verified token through an API route you actually wrote, you'll wonder how you were testing before.
Check out the project on GitHub github.com/whoismaruf/getJwt