Saber se número é par ou impar em JavaScript
Neste artigo você vai aprender a como saber se número é par ou impar em JavaScript, utilizando recursos da própria linguagem de modo fácil.
Em JavaScript, pra saber se um número é par ou ímpar tu usa o operador de resto %, que devolve o que sobra da divisão
Se numero % 2 === 0 o número é par, caso contrário ele é ímpar
const numero = 12
if (numero % 2 === 0) {
console.log("O número é par")
} else {
console.log("O número é ímpar")
}
E sim, zero é par: a definição de par é n = 2k com k inteiro, e 0 = 2 × 0

Fala programador(a), beleza? Bora aprender mais sobre manipulação de números e JavaScript!
Nestes casos de verificar se um número é impar ou par, o mais indicado é utilizar o operador de resto em JavaScript
Pois identificando se o resto de uma divisão é 0 ou não, já conseguimos também verificar se o número é par
Caso o resto seja diferente de 1, o número será impar
Veja uma demonstração prática do operador de resto:
numero = 12
if(numero % 2 === 0) {
console.log("O número é par");
}
Com apenas esta verificação já conseguimos testar se um número é par
Lembrando que o operador de resto em JavaScript é representado pelo símbolo %
Aprenda também
Aprenda a fazer uma busca com caracteres que possuem acentuação neste artigo
Outra técnica muito interessante para elevar o seu conhecimento em JavaScript!
Conclusão
Neste artigo vimos como saber se número é par ou impar em JavaScript
Formação Claude Code
Domine Claude Code do absoluto zero até o avançado
- 120 aulas
- 4 projetos
- 9h 48min
Apenas precisamos utilizar o operador de resto no número, e verificar se o resultado é 0
Caso seja, o número é considerado par, se não ele é impar
Confira também nosso catálogo de cursos gratuitos, com aulas semanais no YouTube
0 é par ou ímpar?
Zero é par, e é par na matemática mesmo, não é uma gambiarra do JavaScript
A definição formal de par é curta: o número pode ser escrito como n = 2k, com k inteiro
E o zero se encaixa redondinho nisso, porque 0 = 2 × 0
Além disso zero é divisível por 2 e o resto da divisão de 0 por 2 é zero, que é exatamente o que a nossa checagem procura
Há consenso de que zero não é ímpar, beleza? não é "meio par", não é "nenhum dos dois"
E se tu travou meio segundo antes de responder, relaxa: estudos de tempo de reação mostram que a maioria das pessoas demora mais pra identificar o 0 como par do que o 2, o 4, o 6 ou o 8
Parte dos professores e alunos também acha que zero é ímpar, ou par e ímpar ao mesmo tempo, ou nenhum dos dois
Ou seja: a confusão é documentada, tu não tá sozinho 🙂
Bônus pra quem curte binário: zero é divisível por qualquer potência de 2, o que dá pra ele um papel especial no sistema que os computadores usam
Por que comparar o resto com 0:
O % do JavaScript é o operador de resto (remainder), ele devolve o que sobra da divisão do primeiro operando pelo segundo
E tem um detalhe que pega MUITA gente: o resultado do % sempre assume o sinal do dividendo, ou seja, do primeiro operando, nunca o do divisor
A MDN exemplifica assim: 13 % 5 devolve 3, e -13 % 5 devolve -3
Sacou o problema? com número negativo o resto pode sair negativo
Por isso a checagem que se sustenta em qualquer sinal é a que compara o resto com 0:
function ehPar(n) {
return n % 2 === 0
}
Tome cuidado! o % é resto, não é o módulo matemático

VPS Hostinger para seu sistema
10% OFF extraVPS com SSD NVMe e backups semanais. O cupom MATHEUSHORADECODAR é aplicado automaticamente pelo link.
Ver planos com 10% OFF →Os dois só divergem quando os operandos têm sinais diferentes: aí o módulo teria o sinal do divisor e os dois resultados podem diferir em uma unidade de d
Se tu precisa do módulo sempre positivo, a documentação indica esta expressão:
((n % d) + d) % d
E se o número vier de um input?
Aí muda o jogo, porque valor de campo de formulário chega como string
Number.isInteger() não faz coerção de tipo: ele devolve false pra qualquer valor que não seja do tipo number, inclusive número escrito como string
Quer dizer que Number.isInteger("10") devolve false, mesmo parecendo um inteiro bonitinho
E isso é diferente do isFinite() global, que converte a string antes de avaliar
Então a ordem que faz sentido é: converte, valida se é inteiro de verdade, e só depois testa a paridade
const valor = Number(entrada)
if (!Number.isInteger(valor)) {
console.log("Digite um número inteiro")
} else if (valor % 2 === 0) {
console.log("O número é par")
} else {
console.log("O número é ímpar")
}
Números gigantes: onde a conta começa a mentir
Number.MAX_SAFE_INTEGER é o maior inteiro que o JavaScript representa com segurança, por causa do formato de ponto flutuante de dupla precisão IEEE 754
O valor é 9007199254740991, que é 2^53 – 1
Acima disso a representação deixa de ser exata, a ponto de Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2 avaliar como true
Insano, né? 😀
Pra esse território existe o BigInt, e o % é sobrecarregado pra dois tipos de operando: number e BigInt
Ele executa o resto de BigInt quando os DOIS operandos são BigInt
if (numero % 2n === 0n) {
console.log("O número é par")
}
Tome cuidado! misturar BigInt com number no % lança TypeError
E o comportamento com divisor zero também muda: 0n lança RangeError, porque BigInt não tem NaN, enquanto o resto de um number por zero devolve NaN
Quando gravei a série da tela de cadastro com HTML, CSS e validações em JavaScript usando orientação a objetos, a parte que mais rendeu foi justamente essa: não confiar no que o usuário digita
A ideia lá era clara e vale aqui também: validação no front é mais um GUIA do que uma trava
Ela mostra pro usuário o que o sistema espera, tipo o campo de e-mail que só aceita o padrão [email protected], e resolve a esmagadora maioria dos casos de gente distraída

Crie sistemas com IA para vender
Prompts, modelos e checklists para criar e publicar seu sistema com IA e preparar a oferta para o primeiro cliente.
Quero o e-book gratuito Receba o livro e os bônus no seu e-mail.Mas quem tem intenção maliciosa passa por cima, então o back valida de novo, sempre
Traz isso pro nosso caso de par ou ímpar: o campo de um formulário nunca te entrega um number, ele te entrega string
É por isso que Number.isInteger("10") devolve false, e é por isso que a checagem de paridade só entra DEPOIS da conversão e da validação
Quem pula essa ordem só descobre o problema quando o formulário já tá no ar 😛
Perguntas frequentes
0 é par ou ímpar?
Zero é par
A definição formal diz que um inteiro é par quando pode ser escrito como n = 2k, com k inteiro, e o zero cumpre isso porque 0 = 2 × 0
Zero é divisível por 2 e o resto da divisão de 0 por 2 é zero, que é justamente o que a checagem em JavaScript procura
Há consenso de que zero não é ímpar
Por que tanta gente erra a paridade do zero?
Porque a dúvida é real e documentada
Estudos de tempo de reação mostram que a maioria das pessoas demora mais pra identificar o 0 como par do que o 2, o 4, o 6 ou o 8
E parte dos professores e alunos acha que zero é ímpar, ou par e ímpar ao mesmo tempo, ou nenhum dos dois
Na matemática, porém, não tem meio termo: zero é par
É "impar" ou "ímpar"?
A grafia correta em português é ímpar, com acento, por ser paroxítona terminada em -r
"Impar" sem acento é outra palavra, um verbo ligado a soluçar
Na busca quase todo mundo digita sem acento, e o código também não liga pra isso, mas na hora de escrever vale o acento 🙂
Por que a checagem compara o resto com 0 e não com 1?
Porque em JavaScript o resultado do % sempre assume o sinal do dividendo, ou seja, do primeiro operando, nunca o do divisor
A MDN exemplifica: 13 % 5 devolve 3, e -13 % 5 devolve -3
Ou seja, com número negativo o resto pode sair negativo
Comparar com 0 se sustenta em qualquer sinal, e é por isso que numero % 2 === 0 é o teste que não quebra
Como conseguir um resto sempre positivo em JavaScript?
O % do JavaScript é resto, não é o módulo matemático
Os dois só divergem quando os operandos têm sinais diferentes: o módulo teria o sinal do divisor e os resultados podem diferir em uma unidade de d
Pra ter o módulo sempre positivo, a documentação indica a expressão ((n % d) + d) % d
Como testar par ou ímpar num valor que veio de um input?
Converte antes, sempre, porque campo de formulário entrega string
Number.isInteger() não faz coerção de tipo e devolve false pra qualquer valor que não seja do tipo number, inclusive número escrito como string
Por isso Number.isInteger("10") devolve false, diferente do isFinite() global, que converte a string
A ordem certa é: Number(entrada), depois Number.isInteger, e só então a checagem com % 2 === 0
E se o número for muito grande?
Aí entra o limite do próprio JavaScript
Number.MAX_SAFE_INTEGER é o maior inteiro representado com segurança por causa do formato de ponto flutuante de dupla precisão IEEE 754, e ele vale 9007199254740991, que é 2^53 – 1
Acima disso a representação deixa de ser exata, tanto que Number.MAX_SAFE_INTEGER + 1 === Number.MAX_SAFE_INTEGER + 2 avalia como true
Pra esses casos existe o BigInt: o % é sobrecarregado pra number e BigInt, executando resto de BigInt quando os dois operandos são BigInt
Misturar BigInt com number no % lança TypeError, e divisor 0n lança RangeError, enquanto o resto de number por zero devolve NaN
Leia também
Formações
Formação Vibe Coding
Do Prompt ao Produto: Crie Software Real com IA
- 474 aulas
- 20 projetos
- 39h 30min
Blog | Mais populares
As diferenças de var, let e const

Como redirecionar para outra página com JavaScript
Exercícios de lógica de programação JavaScript com gabarito
Pratique lógica com JavaScript resolvendo um exercício antes de abrir o gabarito. Execute o código, teste uma entrada comum e um caso de borda, como […]

Se você usar % 12 vc vai pegar o resto da divisão por 12, logo mesmo 6 / 12 daria resto 6 o que falharia no teste.
Precisa ser % 2.
opaaa, era um erro no código, é por 2 mesmo, arrumei já, valeu! =)