JWT Encoder

Створюйте та підписуйте JSON Web Tokens з HS256, HS384, HS512

Заголовок

Працює локально · Безпечно вставляти секрети

Корисне навантаження

Працює локально · Безпечно вставляти секрети

Таємний ключ

Працює локально · Безпечно вставляти секрети

Закодований JWT

Output will appear here…

Ваш таємний ключ ніколи не покидає браузер. Усі підписи виконуються на стороні клієнта.

Також спробуйте:JWT Decoder

Що таке кодування JWT?

Кодування JWT — це процес створення JSON Web Token — компактного рядка, безпечного для URL-адреси, який несе набір претензій, підписаних криптографічним ключем. Результат — трьохчастинний токен (заголовок.корисне навантаження.підпис), визначений у RFC 7519, який сервери можуть перевірити без збереження стану сеансу.

Header оголошує алгоритм підпису (наприклад, HS256) і тип токена. Payload містить claims — пари ключ-значення, такі як суб'єкт (sub), час закінчення дії (exp) та будь-які власні дані, потрібні застосунку. Обидві частини серіалізуються як JSON, а потім кодуються у base64url. Підпис обчислюється над закодованим header і payload за допомогою секретного ключа, зв'язуючи всі три сегменти разом.

На відміну від сесійних cookie, JWT є самодостатніми: для перевірки не потрібно запитувати базу даних або звертатись до зовнішнього сервісу. Це робить JWT-автентифікацію популярною у REST API, мікросервісах та односторінкових застосунках, де без стану авторизація зменшує затримку та спрощує горизонтальне масштабування.

Навіщо використовувати JWT-кодер?

Генерація JWT вручну потребує base64url-кодування, серіалізації JSON та обчислення HMAC. Цей інструмент виконує всі три кроки миттєво, щоб ви могли зосередитись на правильному налаштуванні claims.

Миттєва генерація токенів
Редагуйте header, payload і секрет — підписаний JWT оновлюється в реальному часі. Жодних кроків збірки, встановлення бібліотек чи шаблонного коду.
🔒
Кілька алгоритмів HMAC
Перемикайтесь між HS256, HS384 і HS512 одним кліком. Header оновлюється автоматично, а підпис перераховується негайно.
🛡️
Обробка з пріоритетом конфіденційності
Все підписання відбувається у вашому браузері через Web Crypto API. Ваш секретний ключ і дані payload ніколи не покидають вашу машину — жодного сервера, журналів чи ризиків.
📋
Швидке додавання стандартних claims
Додавайте мітки часу iat, exp+1h або exp+24h одним кліком. Не потрібно вручну обчислювати Unix-мітки часу або шукати поточний час epoch.

Випадки використання JWT-кодера

Тестування фронтенд-автентифікації
Генеруйте токени з певними claims і термінами дії для тестування процесів входу, логіки оновлення токенів і захисту маршрутів без запуску бекенд-сервера автентифікації.
Розробка бекенд API
Створюйте тестові токени з власними claims sub, aud і scope для перевірки middleware авторизації, рольового контролю доступу та перевірки дозволів під час локальної розробки.
DevOps і CI/CD-конвеєри
Генеруйте короткочасні сервісні токени для скриптів розгортання, інтеграційних тестів або міжсервісної комунікації там, де повний OAuth-процес додав би зайву складність.
QA і ручне тестування
Формуйте токени з граничними claims — прострочені токени, відсутні поля, неправильна аудиторія — щоб перевірити, що API повертає правильні відповіді HTTP 401 або 403.
Аудит безпеки
Створюйте токени, підписані різними алгоритмами та ключами різної довжини, щоб перевірити, що ваша логіка верифікації правильно відхиляє слабкі або невідповідні підписи.
Навчання та прототипування
Студенти та розробники, що лише знайомляться з JWT, можуть експериментувати з полями header, структурами claims та алгоритмами підпису, щоб зрозуміти, як працює кожна частина токена.

HS256 проти HS384 проти HS512: порівняння алгоритмів HMAC

Усі три алгоритми використовують HMAC (Hash-based Message Authentication Code) зі спільним секретом. Різниця — в базовій хеш-функції, яка впливає на довжину підпису та рівень безпеки. Для більшості застосунків HS256 забезпечує достатній рівень безпеки. Обирайте HS384 або HS512, коли вимоги відповідності (наприклад, FIPS-140) вимагають більш надійного хешу або коли токени несуть рішення авторизації з високою цінністю.

АлгоритмХешПідписШвидкістьТипове використання
HS256SHA-25632 BFastestGeneral purpose, default for most libraries
HS384SHA-38448 BFastHigher security margin, FIPS-140 compliant
HS512SHA-51264 BFastMaximum HMAC security, large payloads

Довідник стандартних claims JWT

RFC 7519 визначає сім зареєстрованих claims. Жоден не є обов'язковим, але їхнє правильне використання покращує сумісність і безпеку. Claim exp особливо важливий — токени без терміну дії залишаються дійсними необмежено, якщо секрет не ротується.

ClaimНазваОписПриклад
issIssuerWho issued the token"auth.example.com"
subSubjectWho the token represents"user-123"
audAudienceIntended recipient service"api.example.com"
expExpirationUnix timestamp — token invalid after this time1717203600
nbfNot BeforeUnix timestamp — token invalid before this time1717200000
iatIssued AtUnix timestamp when the token was created1717200000
jtiJWT IDUnique token identifier for revocation tracking"a1b2c3d4"

JWT-кодування у коді

Ці приклади показують, як програмно створювати та підписувати JWT. Кожен фрагмент формує валідний токен, підписаний HS256. У виробничих системах завжди встановлюйте claim exp і використовуйте криптографічно випадковий секрет довжиною не менше 256 біт.

JavaScript (Web Crypto API)
async function signJWT(payload, secret, alg = 'HS256') {
  const header = { alg, typ: 'JWT' }
  const enc = new TextEncoder()

  // Base64url encode header and payload
  const b64url = (obj) =>
    btoa(JSON.stringify(obj)).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  const h = b64url(header)
  const p = b64url(payload)

  // Sign with HMAC-SHA256
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(`${h}.${p}`))
  const s = btoa(String.fromCharCode(...new Uint8Array(sig)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

  return `${h}.${p}.${s}`
}

// Usage
const token = await signJWT(
  { sub: 'user-123', name: 'Alice', iat: Math.floor(Date.now() / 1000) },
  'your-256-bit-secret'
)
// → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."
Python (PyJWT)
import jwt
import time

payload = {
    "sub": "user-123",
    "name": "Alice",
    "iat": int(time.time()),
    "exp": int(time.time()) + 3600,  # expires in 1 hour
}

# Sign with HS256 (default)
token = jwt.encode(payload, "your-256-bit-secret", algorithm="HS256")
# → "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOi..."

# Verify and decode
decoded = jwt.decode(token, "your-256-bit-secret", algorithms=["HS256"])
# → {"sub": "user-123", "name": "Alice", "iat": 1717200000, "exp": 1717203600}
Node.js (jsonwebtoken)
const jwt = require('jsonwebtoken')

const payload = {
  sub: 'user-123',
  name: 'Alice',
  role: 'admin',
}

// Sign — iat is added automatically
const token = jwt.sign(payload, 'your-256-bit-secret', {
  algorithm: 'HS256',
  expiresIn: '1h',    // sets exp claim
  issuer: 'auth.example.com',  // sets iss claim
})

// Verify
const decoded = jwt.verify(token, 'your-256-bit-secret')
// → { sub: 'user-123', name: 'Alice', role: 'admin', iat: ..., exp: ... }
Go (golang-jwt)
package main

import (
    "fmt"
    "time"
    "github.com/golang-jwt/jwt/v5"
)

func main() {
    claims := jwt.MapClaims{
        "sub":  "user-123",
        "name": "Alice",
        "iat":  time.Now().Unix(),
        "exp":  time.Now().Add(time.Hour).Unix(),
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    signed, _ := token.SignedString([]byte("your-256-bit-secret"))
    fmt.Println(signed)
    // → eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOi...
}

Часті запитання

У чому різниця між JWT-кодуванням і JWT-декодуванням?
JWT-кодування створює підписаний токен із header, payload і секретного ключа. JWT-декодування виконує зворотну операцію — зчитує закодований у base64url header і payload назад у JSON. Для декодування секрет не потрібен; для кодування він завжди необхідний, оскільки підпис потрібно обчислити.
Яка мінімальна довжина секретного ключа JWT?
Для HS256 використовуйте секрет довжиною не менше 256 біт (32 байти). Для HS384 — не менше 384 біт (48 байтів). Для HS512 — не менше 512 біт (64 байти). Коротші секрети технічно приймаються більшістю бібліотек, але знижують ефективну безпеку підпису HMAC. Генеруйте секрети за допомогою криптографічно безпечного генератора випадкових чисел, а не обраної людиною парольної фрази.
Чи безпечно використовувати цей інструмент із реальними секретними ключами?
Цей інструмент обробляє все у вашому браузері через Web Crypto API — жодні дані не надсилаються на жодний сервер. Проте як загальна практика безпеки уникайте вставлення виробничих секретів у будь-який вебінструмент. Для управління виробничими ключами використовуйте змінні середовища або менеджер секретів, наприклад HashiCorp Vault або AWS Secrets Manager.
Що краще обрати для застосунку — HS256 чи RS256?
Використовуйте HS256, коли один і той самий сервіс і створює, і перевіряє токени — це швидше і простіше. Використовуйте RS256 (асиметричний), коли стороннім сервісам потрібно перевіряти ваші токени без можливості їх створювати. RS256 поширений у провайдерах OAuth 2.0, OpenID Connect та багатоорендних SaaS-архітектурах.
Чому мій JWT одразу закінчується після створення?
Claim exp використовує Unix-мітки часу в секундах, а не мілісекундах. Якщо ви встановлюєте exp у Date.now() (що повертає мілісекунди), токен виглядатиме так, ніби закінчується за тисячі років — або якщо випадково використати значення в мілісекундах там, де очікуються секунди, бібліотеки можуть інтерпретувати його як уже прострочений. Завжди використовуйте Math.floor(Date.now() / 1000) у JavaScript або int(time.time()) у Python.
Чи можна зберігати чутливі дані у payload JWT?
Можна, але не варто. Payload JWT закодований у base64url, а не зашифрований — будь-хто з токеном може прочитати claims. Не зберігайте паролі, номери кредитних карток або персональні дані у payload. Якщо необхідно включити конфіденційну інформацію, використовуйте JWE (JSON Web Encryption) відповідно до RFC 7516, який шифрує весь payload.
Що відбувається, якщо змінити payload після підписання?
Підпис стає недійсним. Підпис HMAC обчислюється над точними байтами закодованого header і payload. Будь-яка зміна — навіть додавання пробілу або зміна одного символу — призводить до абсолютно іншого підпису. Правильно реалізований верифікатор відхилить токен з помилкою невідповідності підпису.