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 Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

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

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

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 😛