Skip to content

Lanzar Moneda Online

Última verificación mayo 2026 — corre en tu navegador
Lanzar moneda
?

Lanzar Moneda Online — Cara o Cruz Aleatorio (Simulador)

¿Necesitas un lanzamiento de moneda justo sin buscar una en el bolsillo? Esta moneda online tira cara o cruz con una animación 3D CSS de 600 milisegundos y luego registra el resultado, para que puedas zanjar una apuesta, decidir quién empieza o hacer una demostración estadística rápida sin perder la cuenta. Cada pulsación del botón es un ensayo independiente, así que el ratio acumulado cara/cruz se acerca a 50/50 cuanto más lances — útil cuando quieres una demostración visible de la ley de los grandes números y no un único resultado binario.

Relacionados: Lanzar dados Número aleatorio Qué comer Selector de equipos Lanzar moneda Calculadora de porcentaje
Sobre esta herramienta

Cada lanzamiento llama a la Web Crypto API del navegador (crypto.getRandomValues) y usa rejection sampling para elegir 0 ó 1 sin sesgo de módulo — la misma fuente de entropía que usan los gestores de contraseñas modernos y TLS. Evitamos Math.random() a propósito, que es rápido pero no criptográficamente aleatorio y puede mostrar patrones sutiles en tiradas muy largas. El resultado se renderiza con una animación CSS rotateY de 2520 grados, así que la moneda aterriza en la cara elegida desde la misma posición inicial cada vez, y el contador + historial persisten durante la sesión para que puedas auditar la racha después. Usos habituales: zanjar una decisión justa cuando no tienes moneda a mano, arrancar un partido online, demostrar probabilidad de lanzamiento de moneda en clase o comprobar que el sorteo del cuadro de tu torneo fue realmente aleatorio.

  • Resultado criptográficamente aleatorio vía Web Crypto (sin sesgo de Math.random)
  • Animación 3D CSS rotateY de 600 ms, sin librerías JS de animación
  • Contador acumulado de caras vs cruces durante la sesión
  • Historial cronológico completo (secuencia C/X)
  • Botón de reinicio para borrar contador y empezar de nuevo
  • Funciona sin conexión una vez cargada la página — sin ida y vuelta al servidor por lanzamiento
  • Sin cuentas, sin cookies, sin seguimiento de los resultados individuales
  • Pulsación cómoda en móvil — usable con una sola mano
  • Accesible por teclado: Espacio o Enter dispara el lanzamiento
  • Apto para desempates, demos en clase y decisiones imparciales

Gratis. Sin registro. Tus datos permanecen en tu navegador. Anuncios mediante Google AdSense (con consentimiento).

Preguntas frecuentes

¿Es realmente justa la moneda, 50/50 cada lanzamiento?

Sí, matemáticamente. Cada lanzamiento llama a `crypto.getRandomValues()` (W3C Web Cryptography API, Recomendación de 26 de enero de 2017) y usa rejection sampling para mapear un entero uniforme de 32 bits a 0 o 1. Como 2 divide a 2³² de forma exacta, no entra sesgo de módulo — cada lanzamiento es un ensayo Bernoulli(0,5) independiente. La animación CSS rotateY de 600 milisegundos es puramente visual; el resultado se decide al inicio del clic y solo se revela tras la animación. En contraste, las monedas físicas no son perfectamente 50/50: el análisis mecánico de Diaconis, Holmes y Montgomery 2007 (SIAM Review 49(2):211–235) estima un sesgo de ~50,8 %/49,2 % hacia el mismo lado en el que empezaron en el típico lanzamiento de pulgar (sin rebote); la replicación de Bartoš et al 2024 sobre 350.757 lanzamientos midió Pr(mismo lado) = 0,508 con márgenes de error ajustados. La moneda virtual elimina ese sesgo físico íntegramente.

¿Por qué mi serie de 10 lanzamientos sale 7 caras en lugar de 5?

Las series cortas no convergen. El número de caras de una moneda justa en 10 lanzamientos sigue una distribución Binomial(10, 0,5): 5 caras es el resultado individual más probable con un 24,6 %, pero 7 caras pasa alrededor del 11,7 % de las veces (y el simétrico de 3 caras otro 11,7 %). La desviación absoluta esperada respecto a 5 caras es √(10 × 0,5 × 0,5) ≈ 1,58. La Ars Conjectandi de Jakob Bernoulli (1713) demostró la Ley de los Grandes Números: el ratio observado caras/cruces converge en probabilidad a 50/50 cuando el número de ensayos crece, pero "converge" admite desviaciones arbitrariamente largas a corto plazo. El conjunto de datos de Pearson y Weldon de 1900 (26.306 lanzamientos de 12 dados) es el ejemplo clásico — la prueba chi-cuadrado de bondad de ajuste que introdujeron es la que usan los estadísticos para decidir si una frecuencia observada es compatible con una moneda justa o trucada.

¿Podría el resultado depender de cuándo pulso el botón?

No. La aleatoriedad viene de `crypto.getRandomValues()`, que lee del pool de entropía del SO (entropía a nivel de kernel y resolución de microsegundos procedente de interrupciones, fuentes de ruido hardware y rdrand en x86 si está disponible). El timing del clic podría sesgar un `Math.random()` sembrado desde `Date.now()`, pero `crypto.getRandomValues()` no está sembrado por nada observable o influenciable desde JavaScript. Lo mismo aplica al timing de pulsaciones de teclado en el pool de entropía: aunque el patrón de clic del usuario afecte al pool del kernel ligeramente (lo hace, por diseño, para mezclar entrada impredecible), los más de 256 bits de entropía acumulada que mantiene un SO típico hacen que cualquier sesgo de un único usuario sea indetectable.

¿Por qué no usar simplemente Math.random()? ¿Lo notaría alguien?

Para un lanzamiento aislado nadie lo notaría. En una serie larga aparecen dos problemas: (1) sesgo estadístico — el xorshift128+ de V8 (usado desde Chrome 49 estable en marzo de 2016) pasa BigCrush pero no todas las pruebas de linealidad (Lemire y O'Neill 2018, arXiv:1810.05313, señalaron fallos estructurales en xorshift128+ y xoroshiro128+), y cualquier comportamiento visible para el usuario que dispare "reiniciar" + relanzar podría estar sutilmente sesgado por la estructura periódica; (2) predictibilidad — el estado de `Math.random()` se puede recuperar a partir de unos pocos cientos de salidas mediante resolución de restricciones con el demostrador SMT Z3 (demostración de Lemire 2017 sobre xoroshiro128+, aplicable de forma similar a xorshift128+), lo que lo hace inadecuado para cualquier decisión que alguien quiera manipular. `crypto.getRandomValues()` no tiene ninguna de esas propiedades: el estado es interno del SO, no se expone al script, y se re-siembra continuamente desde ruido hardware.

¿Por qué dos formas de mostrar cara o cruz — letras o palabras?

La forma de letra única (H/T en inglés, C/X en español) dentro de la cara de la moneda es para la propia moneda animada, donde el espacio es limitado y la letra necesita leerse como un glifo tipográfico a 2,5rem. La palabra entera (Heads/Tails o Cara/Cruz) aparece en la etiqueta de resultado debajo de la moneda para mayor claridad — es el resultado textual que los lectores de pantalla anuncian vía la región `aria-live="polite"` según WCAG 2.1 SC 4.1.3 Mensajes de Estado (Recomendación W3C de 5 de junio de 2018), de modo que los usuarios no videntes escuchen "Cara" en lugar de deletrear la letra "C". La tira de historial vuelve a usar letras porque muestra una secuencia cronológica y necesita encajar muchos lanzamientos horizontalmente.

Fuentes (9)
  • World Wide Web Consortium (W3C) (2017). Web Cryptography API — `crypto.getRandomValues()` plus rejection sampling pick 0 or 1 with exactly 50/50 probability per flip; same source modern password managers and TLS handshakes use; ECMA-262 `Math.random()` (V8 xorshift128+ since 4.9.41, Chrome 49 stable March 2016) is fast but not cryptographically random and is not the appropriate primitive for security-sensitive coin tosses. W3C Recommendation 26 January 2017 (Crypto.getRandomValues §3.3).
  • Bernoulli, J. (1713). Ars Conjectandi (The Art of Conjecturing) — first formal proof of the Law of Large Numbers (Pars Quarta, the fourth part): as the number of independent Bernoulli trials grows, the observed proportion of successes converges in probability to the true success probability; for a fair coin this means the heads/tails ratio approaches 50/50 as the flip count grows, which is what the running tally on this page demonstrates flip by flip. Thurnisius, Basel, posthumous publication eight years after Jakob Bernoulli's 1705 death; ISBN 0-8018-8235-4 (Sylla 2006 Johns Hopkins University Press English translation).
  • Pearson, K. (1900). On the criterion that a given system of deviations from the probable in the case of a correlated system of variables is such that it can be reasonably supposed to have arisen from random sampling — introduced the chi-square goodness-of-fit test, the canonical statistical procedure for asking "is this coin fair?" given an observed heads/tails frequency; Weldon's 26,306 dice tosses dataset analysed in this paper detected a small bias toward five and six on real wooden dice of the era. Philosophical Magazine, Series 5, Vol. 50, No. 302, pp. 157–175 (July 1900).
  • Knuth, D. E. (1997). The Art of Computer Programming, Volume 2: Seminumerical Algorithms — Chapter 3 "Random Numbers" — formal treatment of pseudo-random number generation, including the modulo-bias proof: when the underlying RNG range (here, 2^32 from a Uint32Array) is not divisible by the desired bound (2 for heads/tails), naive `r % 2` is unbiased only because 2 divides 2^32 evenly; for non-divisor bounds rejection sampling is necessary. Addison-Wesley, 3rd edition (1997, ISBN 0-201-89684-2); Ch. 3 dates from 1st edition 1969.
  • Diaconis, P., Holmes, S., & Montgomery, R. (2007). Dynamical Bias in the Coin Toss — mechanical analysis of the typical thumb-flip-and-catch coin toss shows a residual ~50.8 % bias toward the same side the coin started; the bias is dominated by the small wobble that keeps one side facing up slightly more than the other during the flight; subsequent replications (Bartoš et al 2024, 350,757 flips: Pr(same side) = 0.508) confirm the magnitude. SIAM Review 49(2) pp 211-235 (May 2007); DOI 10.1137/S0036144504446436.
  • Lemire, D., & O'Neill, M. E. (2018). Xorshift1024*, Xorshift1024+, Xorshift128+ and Xoroshiro128+ Fail Statistical Tests for Linearity — found that the xorshift128+ algorithm V8 uses for `Math.random()` (since Chrome 49 / V8 v4.9.41) passes the BigCrush battery overall but fails specific linearity-detection tests; the failures are subtle and do not affect typical Monte-Carlo simulations but make these generators unsuitable for adversarial settings. Journal of Computational and Applied Mathematics 350 (April 2019) pp 86-94; pre-print arXiv:1810.05313 (October 2018).
  • Lemire, D. (2017). Cracking random number generators (xoroshiro128+) — demonstrates that the internal state of xoroshiro128+ (and by extension the closely related xorshift128+ used by V8 `Math.random()`) can be recovered from a few hundred outputs via Z3 SMT theorem-prover constraint solving; the consequence is that any decision driven by `Math.random()` can be predicted by an adversary who observes enough draws. Personal blog at lemire.me, 22 August 2017; GitHub demonstration at github.com/lemire/crackingxoroshiro128plus.
  • Vigna, S. (2014). Further scramblings of Marsaglia's xorshift generators — defines xorshift128+, the algorithm V8 (Chrome, Node.js, Edge, Opera) and SpiderMonkey (Firefox) use as the implementation of `Math.random()`; replaces the older MWC1616 that V8 used pre-v4.9.41. Journal of Computational and Applied Mathematics 315 (May 2017) pp 175-181; pre-print arXiv:1404.0390 (April 2014, last revised 2016).
  • World Wide Web Consortium (W3C) (2018). Web Content Accessibility Guidelines (WCAG) 2.1 — Success Criterion 4.1.3 Status Messages — the flip result and running tally update via `aria-live="polite"` regions so screen reader users hear each outcome without losing keyboard focus on the flip button. W3C Recommendation 5 June 2018; carried unchanged into WCAG 2.2 (Recommendation 5 October 2023).

Son las publicaciones originales en las que se basan las fórmulas de esta herramienta. Localízalas con el nombre de la revista y el año en Google Scholar o PubMed.

Por ·