Conversor de Timestamp
Converta um timestamp Unix em uma data legível - e vice-versa. Você obtém segundos, milissegundos, ISO 8601, UTC, hora local, o dia da semana, uma string RFC
Converta entre timestamps Unix e datas legíveis, nos dois sentidos e tanto em segundos quanto em milissegundos. Cole 1735689600 ou 2026-01-01T00:00:00Z e veja o equivalente em UTC, no seu fuso horário local e em formatos comuns como ISO 8601 e RFC 2822.
Isso aparece o tempo todo ao ler logs, ao depurar uma API que devolve segundos epoch ou ao conferir se a expiração de um token é o que você imagina. A conversão é exata e roda localmente, e avisa quando um valor parece estar em milissegundos em vez de segundos.
Como converter um timestamp Unix
Cole um timestamp ou uma data
Leia os valores convertidos em UTC e no horário local
Copie o formato que você precisa
Perguntas frequentes
Segundos ou milissegundos?
Dez dígitos costumam ser segundos e treze costumam ser milissegundos. A ferramenta detecta a unidade provável e deixa você trocá-la se o resultado parecer errado.
O que é a época Unix?
A contagem de segundos desde 1º de janeiro de 1970 00:00:00 UTC, sem contar os segundos intercalares. É a forma padrão de armazenar um instante no tempo.
Qual fuso horário é usado?
Os dois são mostrados: UTC e o fuso horário local do seu navegador, para você comparar o que o servidor registra com o que você vê no relógio.
A ferramenta aceita datas anteriores a 1970?
Sim, valores negativos representam datas antes da época, e datas muito distantes no futuro funcionam até os limites do intervalo de datas do JavaScript.
Ela consegue gerar o timestamp de uma data?
Sim, a conversão funciona nos dois sentidos - informe uma data e receba o valor epoch.
Alguma coisa é enviada para algum servidor?
Não, a conversão é aritmética local.
Visão geral
| Entrada | texto |
|---|---|
| Vários arquivos | Não |
| Onde roda | No seu navegador - os arquivos nunca são enviados |
| Funciona offline | Sim — depois que a página carrega |
| Preço | Grátis, sem cadastro, sem marca d'água |
Onde as conversões quebram em silêncio
A maioria dos bugs de conversão não é de sintaxe, e sim de significado. Uma coluna CSV de códigos postais perde os zeros à esquerda no momento em que a planilha supõe que aquilo é um número; um ID longo ultrapassa a precisão de ponto flutuante; datas mudam de sentido dependendo de o dia vir antes do mês ou o mês antes do dia. As chaves do JSON não têm ordem, mas os arrays têm, e uma ferramenta que ordena chaves não muda nada, enquanto uma que ordena arrays altera os dados. O Unicode é outra armadilha: o texto pode chegar como UTF-8, UTF-16 ou com um BOM, e um decodificador que erra o palpite transforma caracteres acentuados em mojibake. Antes de confiar em qualquer conversão, confira por amostragem a primeira e a última linha, qualquer campo com zeros à esquerda e qualquer campo que contenha aspas, vírgulas ou quebras de linha.
Como escolher um formato de dados
O JSON é o padrão para tudo que uma API retorna ou um programa lê: ele lida naturalmente com estruturas aninhadas, números, booleanos e null, e toda linguagem o interpreta. O CSV é menor e abre direto em uma planilha, mas não tem como expressar aninhamento nem um padrão comum para o delimitador, as aspas ou o conjunto de caracteres - e é exatamente aí que as conversões dão errado. O XML é verboso, mas carrega atributos, conteúdo misto e esquemas, por isso ainda domina formatos de documento e integrações legadas. O YAML é o mais legível para configuração, mas é sensível a espaços em branco e tem conversões de tipo surpreendentes ("no" virando false, uma versão como 1.10 virando 1.1). Escolha o formato que a ferramenta que vai consumir os dados prefere, e não o que parece mais bonito.