logo
GeekFormat

Ferramenta JWT

Encoded Token172 charsAtualizado em 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Assunto1234567890
name· NameJohn Doe
admin· Admintrue
iat· Emitido em151623902218/01/2018, 09:30:22
Header details2 items
algHS256HMAC (simétrico)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Decodifique, verifique e gere JWT Token online e grátis. Visualize Header, Payload e informações de assinatura. Ideal para depuração de autenticação de APIs.

Sugestões Relacionadas

Casos de uso

  • Decodificar JWT online: dividir rapidamente um token durante a depuração de login OAuth 2.0 / OIDC para inspecionar algoritmo do Header e Claims do Payload
  • Verificar assinaturas JWT: use um Secret / chave pública para validar assinaturas de token em tempo real e decidir se um 401 é 'assinatura ruim', 'expirado' ou 'algoritmo incompatível'
  • Gerar JWTs de teste durante integração: emita um JWT no navegador com um par de chaves de teste, sem precisar que o backend altere temporariamente o código para gerar um token
  • Conversão PEM ↔ JWK: o OIDC IdP te deu JWK mas o servidor precisa de PEM (ou vice-versa) — converta no lugar em vez de escrever um script OpenSSL
  • Diagnosticar 401 Unauthorized: verifique expiração, correspondência alg-vs-gateway, correspondência de chave e formatação PEM passo a passo
  • Comparar RS256 vs PS256: muitos provedores OIDC usam RS256 por padrão enquanto AWS SigV4 prefere PS256 — troque algoritmos com o mesmo par de chaves RSA e compare resultados
  • Aprender internals do JWT: mude o alg, edite o Payload, troque a chave no navegador e veja a assinatura quebrar em tempo real — muito mais rápido que ler o RFC

Recursos

  • Decodificar + Verificar + Gerar em um só lugar: cole um token para dividir Header/Payload/Signature, troque algoritmo e chave para verificar a assinatura, edite Claims e reassine para produzir um novo token — cobre toda a cadeia de solução de problemas JWT
  • Todos os 13 algoritmos suportados: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — cobre OAuth 2.0, OIDC, JWS, gateways de API e SSO empresarial
  • Formatos PEM e JWK: chaves RSA, ECDSA e Ed25519 aceitam strings PEM (com cabeçalhos -----BEGIN PUBLIC KEY-----) e JSON JWK (campos kid/kty/n/e) — insira diretamente a saída OIDC /.well-known/jwks.json
  • Múltiplas formas de entrada de segredo HMAC: string UTF-8 bruta, bytes hex ou codificado Base64/Base64URL — troque com um clique, para que 'parece igual mas assinatura falha' nunca aconteça
  • Geração automática de par de chaves: pares de chaves RSA-2048, RSA-4096, P-256, P-384 e Ed25519 gerados no navegador, apresentados em formatos PEM e JWK para uso imediato em testes
  • Destaque semântico de Claims: exp / iat / nbf convertidos automaticamente para hora legível com status expirado / ainda-não-válido / emitido destacado; alg / typ / kid no Header rotulados individualmente
  • 100% no lado do cliente, zero upload: cada parse, verify e sign roda via Web Crypto API nativo do navegador — tokens, chaves e payload nunca saem do navegador, seguindo o princípio de segurança de 'nunca colar tokens de produção em ferramentas online aleatórias'
  • Cópia com um clique: Header, Payload, Signature e o token recém-gerado são copiáveis independentemente para documentação, tickets e comandos curl

Como Usar

  1. Cole ou digite o token: coloque a string JWT no campo de entrada; a ferramenta divide automaticamente Header, Payload e Signature e exibe cada um como JSON formatado
  2. Selecione o algoritmo: alterne entre HS256 / RS256 / ES256 / PS256 / EdDSA; a ferramenta infere do Header.alg e sinaliza qualquer incompatibilidade
  3. Importe uma chave: cole um segredo HMAC, uma string PEM ou um JSON JWK; para algoritmos assimétricos, clique em 'Gerar par de chaves' para obter uma chave de teste imediatamente
  4. Verifique ou reassine: no modo Decode, verifique com chave pública e veja '✅ assinatura válida / ❌ assinatura inválida'; no modo Encode, edite Claims e assine com chave privada para produzir um novo token

Perguntas frequentes

Quais são as três partes de um JWT?

Uma string JWT tem a forma `Header.Payload.Signature`, cada segmento é codificado em Base64URL. O Header declara o algoritmo (como HS256, RS256) e o tipo de token (typ: JWT); o Payload carrega Claims do usuário (declarações), campos comuns são sub (ID do usuário), iat (tempo de emissão), exp (tempo de expiração), nbf (not-before), aud (audiência), iss (emissor); a Signature é o resultado da assinatura dos dois primeiros segmentos com uma chave, o objetivo é 'detecção de violação' não 'anti-vazamento'.

Posso editar o Payload após decodificar?

Você pode visualizar e editar, mas **não falsificar**. Assim que você alterar o Header ou Payload, a Signature original se torna inválida e o servidor rejeitará a verificação. Para tornar o token modificado válido novamente, você deve **reassinar** com o mesmo algoritmo e mesma chave — é exatamente por isso que esta ferramenta oferece 'decodificar + editar + gerar' em um só lugar: decodifique para visualizar, altere e gere imediatamente um novo token para teste, para que você não precise pedir ao backend para alterar temporariamente o código para emitir.

Qual é a diferença entre HS256, RS256, ES256, PS256 e EdDSA?

HS256 usa HMAC com segredo compartilhado (simétrico), rápido mas gerenciamento de segredo é crucial. RS256 usa chaves privada/pública RSA (assimétrico), o emissor assina com privada, o verificador usa pública. ES256 usa ECDSA com curvas elípticas (P-256), assinatura mais curta. PS256 usa RSA-PSS, mais seguro que RS256. EdDSA (geralmente Ed25519) é rápido e determinístico, recomendado para OAuth 2.1.

Por que meu JWT continua mostrando 'Invalid Signature'?

Geralmente é porque a chave, formato do segredo, algoritmo ou codificação Base64URL não coincidem exatamente. Um espaço extra, nova linha PEM incorreta ou confusão entre Base64 e Base64URL é suficiente. Verifique byte a byte e confirme que Header.alg corresponde ao algoritmo selecionado.

A mesma chave RSA pode verificar RS256 e PS256 cruzadamente?

Não. RS256 usa RSASSA-PKCS1-v1_5, PS256 usa RSA-PSS. Mesmo com a mesma chave RSA, eles não podem verificar cruzadamente. Signatário e verificador devem usar o mesmo algoritmo.

O que é um ataque alg:none?

Um atacante muda o Header para `{"alg":"none"}` (sem assinatura) ou substitui RS256 por HS256 (usando a chave pública como se fosse um segredo HMAC). O servidor deve impor uma lista de permissões de algoritmos e nunca deixar o token decidir qual algoritmo usar.

Como converto entre PEM e JWK?

PEM é a notação clássica do OpenSSL com linhas BEGIN/END. JWK é JSON e é comum em OAuth/OIDC. Provedores OIDC frequentemente publicam chaves públicas via `/.well-known/jwks.json`. Esta ferramenta pode processar formatos PEM e JWK diretamente.

O navegador pode verificar assinaturas JWT diretamente?

Sim. O Web Crypto API nativo do navegador (`window.crypto.subtle`) suporta assinatura e verificação HMAC, RSA, ECDSA, RSA-PSS e Ed25519, sem bibliotecas de terceiros. Esta ferramenta usa `crypto.subtle.importKey` e `crypto.subtle.verify` no front-end para cada verificação, por isso nunca envia seus tokens ou chaves. Nota: Web Crypto está disponível apenas em contextos seguros: **HTTPS** ou `localhost`.

Meu token é enviado para um servidor?

Não. Todo parsing, verificação e assinatura nesta ferramenta roda no navegador via Web Crypto API nativo. O token, Header, Payload, Signature, segredo / chave privada e quaisquer pares de chaves gerados nunca são enviados para um servidor. Abra a aba Network do DevTools do navegador e você não verá nenhuma requisição de saída carregando conteúdo do token. A página pode ser usada offline após ser carregada.

JWT é um lugar seguro para informações sensíveis do usuário?

**Não.** O Payload JWT é texto plano por padrão — qualquer um com o token pode decodificar em Base64URL e ler o conteúdo. Não há criptografia. **Nunca coloque** senhas, números de documentos, números de cartão de crédito, chaves de API, access tokens ou refresh tokens em texto plano em um JWT. Se você precisa de criptografia, use JWE (RFC 7516) em vez de JWS. JWTs são apropriados para Claims não sensíveis (ID do usuário, função, expiração, ID do tenant); dados sensíveis devem ser consultados no lado do servidor usando `sub`.

O que é Decodificar, Verificar e Gerar JWT?

JWT (JSON Web Token) é um padrão aberto definido pelo IETF no RFC 7519 (RFC 7515 descreve a forma de assinatura JWS, RFC 7516 descreve criptografia JWE, RFC 7517 define chaves JWK) para transferir com segurança informações de usuário 'declaradas' entre requisições HTTP, fluxos OIDC e chamadas de microsserviços. Uma string JWT padrão é composta por três segmentos codificados em Base64URL: Header (algoritmo e tipo), Payload (Claims, os dados do usuário) e Signature (uma assinatura baseada em chave sobre os dois primeiros). Os três segmentos são unidos por um ponto `.`, ex.: `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT não é criptografia.** Este é o equívoco mais comum. O Payload é texto plano por padrão — qualquer um pode decodificar em Base64URL e ler o conteúdo. JWT fornece **detecção de violação**, não confidencialidade: o servidor reassina Header.Payload com a chave compartilhada e compara com a Signature do token. Se coincidirem, o token não foi alterado em trânsito. Esta é a metáfora do 'bilhete de trem com carimbo antifalsificação': o inspetor se importa se o bilhete é genuíno, não se o QR code está ilegível.

JWT divide responsabilidades claramente entre 13 algoritmos. **Família HMAC** (HS256/HS384/HS512) usa uma chave simétrica para assinatura e verificação, rápida e simples, adequada para um único serviço ou cluster confiável; o segredo deve ter pelo menos o comprimento do digest (ex.: ≥ 32 bytes para HS256). **Família RSA** (RS256/RS384/RS512) usa RSASSA-PKCS1-v1_5, o esquema assimétrico mais comum — signatários têm a chave privada, verificadores têm a chave pública. **Família RSA-PSS** (PS256/PS384/PS512) usa o preenchimento RSA-PSS mais recente com garantias de segurança mais fortes, preferido por AWS SigV4 e provedores de identidade OIDC modernos. **Família ECDSA** (ES256/ES384/ES512) usa curvas elípticas (P-256/P-384/P-521 respectivamente) com assinaturas mais curtas e melhor desempenho. **EdDSA** (principalmente Ed25519) é extremamente rápido e determinístico (mesma mensagem + mesma chave = mesma assinatura sempre) e é o algoritmo recomendado no OAuth 2.1 e novos protocolos.

Segurança é onde JWT tropeça em produção. O OWASP JWT Cheat Sheet destaca pelo menos quatro regras rígidas: (1) nunca coloque senhas, documentos de identidade, números de cartão ou chaves de API como texto plano no Payload; (2) o servidor deve **nunca confiar no campo alg** declarado no Header do Token — deve verificar com um algoritmo fixo, caso contrário um atacante reescrevendo o header para `alg: none` contorna tudo (esta é a raiz de CVEs históricos como CVE-2015-9235); (3) segredos HMAC devem ser aleatórios e ter pelo menos 32 bytes, nunca strings curtas; (4) verificação é mais do que apenas verificações de assinatura — você também deve validar `exp` (expiração), `nbf` (not-before), `iss` (emissor) e `aud` (audiência). Esta ferramenta destaca cada um desses Claims na interface para que você possa dizer à primeira vista se uma falha é um problema de assinatura, um problema de tempo ou um problema de Claims.

JWT não é um substituto para sessões. Sessões armazenam estado do usuário no servidor (Redis ou banco de dados); JWT empacota o estado no token. Arquiteturas de microsserviços, APIs sem estado, clientes móveis e configurações com muito CORS se beneficiam do JWT; sistemas empresariais tradicionais e fluxos que requerem revogação instantânea (ex.: 'expulsar este usuário agora') ainda são melhor atendidos por sessões. Esta ferramenta cobre tanto depuração pura de JWT quanto as etapas de parsing de Token / verificação de assinatura / edição de Payload de uma migração de sessão para JWT.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgoritmo de chave simétrica: o mesmo Secret assina e verifica. É simples e rápido, indicado para clusters de serviços dentro de um limite confiável. O Secret deve ter pelo menos 32 bytes para HS256, 48 para HS384 e 64 para HS512.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIO algoritmo assimétrico mais comum. A assinatura é feita com a chave privada e a verificação com a chave pública. É o padrão em muitos provedores OIDC, gateways de API e SSO corporativo.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS é a substituição mais moderna e segura para RS256. AWS SigV4, AWS Cognito e provedores OIDC atuais tendem a preferi-lo. Defina saltLength explicitamente para a verificação bater.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APIAssinaturas com curvas elípticas. Produzem assinaturas curtas (ES256 tem apenas 64 bytes), são rápidas e deixam o JWT menor. O Sign in with Apple usa ES256 por padrão.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgoritmo de assinatura moderno e muito rápido. As assinaturas são determinísticas (mesma mensagem + mesma chave = mesma assinatura), sem risco de reutilização de nonce, e funcionam bem em protocolos novos.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Esta bancada JWT roda 100% no seu navegador, apoiada pelo Web Crypto API nativo do navegador. O token que você cola, o Header, o Payload, a Signature, o Segredo HMAC, quaisquer chaves privadas RSA/ECDSA, quaisquer pares de chaves gerados e cada cálculo de assinatura/verificação permanecem no seu dispositivo — eles nunca viajam para um servidor, nunca são registrados, nunca analisados e nunca armazenados em cache. A página pode ser usada offline após ser carregada. Melhor prática: nunca cole tokens de produção de longa duração ou chaves privadas de produção em nenhuma ferramenta online, incluindo esta. Esta ferramenta é apropriada para depuração, teste de integração, aprendizado e geração de tokens de teste — segredos de produção e chaves privadas devem ser tratados em um ambiente controlado e local.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

O token e a chave de verificação não coincidem. As causas usuais: (1) a chave do servidor e a chave que você colou na ferramenta são diferentes (mais comum); (2) a chave contém caracteres invisíveis (espaço final, nova linha, caractere de largura zero); (3) Base64 e Base64URL estão misturados; (4) o algoritmo errado está selecionado (Header diz HS256, servidor verifica como RS256, ou vice-versa). Primeiro verifique se a chave coincide byte a byte: preste atenção às novas linhas finais do PEM, espaços finais do segredo HMAC e valores `k` do JWK que podem ter sido decodificados por URL incorretamente. Confirme se o algoritmo na ferramenta corresponde ao Header.alg do token. Use o decode-plus-verify desta ferramenta para reproduzir o erro exato e confirmar que acontece entre 'decodificação bem-sucedida' e 'verificação falhou'.

HTTP 401 Unauthorized: Token Expired ou iat no futuro

Verificação de assinatura passou, mas `exp` está no passado (Token Expired), `nbf` ainda está no futuro (Not Before) ou `iat` é posterior ao tempo atual do servidor (frequentemente por dessincronização de relógio). Outro caso comum é `aud` (audiência) incompatível: o token foi emitido para o App A mas validado pelo App B. Use a área de Claims destacada nesta ferramenta para ver o status exp / nbf / iat à primeira vista. exp vermelho = expirado, reemita. nbf vermelho = ainda não válido, verifique se iat é um tempo futuro. aud vermelho = audiência errada, verifique se o servidor tem a audiência correta configurada.

Erro de importação PEM ou JWK

PEM tem linhas vazias extras ou falta marcadores de cabeçalho/rodapé (`-----BEGIN PUBLIC KEY-----`); JWK falta campos obrigatórios (`kty` / `n` / `e` / `kid`); valor `k` do JWK falta preenchimento Base64URL (deve ser preenchido com `=` ou estritamente sem `=`); uma chave privada RSA está sendo importada como chave pública; uma chave privada Ed25519 (seed de 32 bytes) está sendo fornecida como 64 bytes. Reexporte um PEM PKIX padrão com `openssl rsa -in key.pem -pubout -outform PEM` ou `openssl ec -in key.pem -pubout`; para JWK, use a saída bruta do endpoint OIDC Discovery `/.well-known/jwks.json` em vez de codificar manualmente. Esta ferramenta detecta automaticamente cabeçalhos PEM, preenchimento faltando e campos JWK faltando e fornece uma dica.

RS256 vs PS256 falhas de assinatura entre linguagens

RS256 usa RSASSA-PKCS1-v1_5, PS256 usa RSA-PSS. Os dois **não podem verificar cruzadamente** — um token assinado com RS256 por uma determinada chave RSA sempre falhará na verificação PS256, e a assinatura pode diferir em comprimento por alguns bytes. Certifique-se de que o signatário e o verificador usem o mesmo algoritmo. AWS SigV4 usa PS256, a maioria dos OIDC IdPs usa RS256. RSA-PSS também tem um parâmetro `saltLength` — OpenSSL padrão 32, jose padrão 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` do Go é o equivalente correto. Trave isso antes de testar integração entre linguagens.

Ataque alg: none e ataque de substituição de chave HS256

O servidor escolhe um algoritmo de verificação com base no alg declarado no Header do token. Um atacante reescreve o header para `alg: none` (sem assinatura) ou reescreve um token RS256 para HS256 (usando a chave pública como se fosse um segredo HMAC compartilhado) e contorna a verificação. CVEs históricos como CVE-2015-9235 (jsonwebtoken) e CVE-2022-23529 (múltiplas bibliotecas Node) remontam a este padrão. O servidor deve impor uma lista de permissões de algoritmos — por exemplo `algorithms: ['RS256']` — e nunca deixar o token decidir qual algoritmo usar. A interface desta ferramenta mostra tanto Header.alg quanto o algoritmo que você realmente selecionou, e sinaliza incompatibilidades: isso é uma demonstração ao vivo de 'o cliente não deve confiar em Header.alg'.