Alguien envía tu formulario con un correo electrónico no válido. Tu formulario lo acepta. El correo de bienvenida rebota. Esa persona no vuelve a saber de ti. Otra persona envía el formulario sin rellenar campos obligatorios. El formulario sigue adelante. Tu equipo se queda con datos incompletos. Ambos fallos ocurren porque la validación falta o está mal hecha.
La validación es el proceso de comprobar que los datos del formulario son válidos antes de aceptarlos. Ocurre en dos sitios: el navegador y el servidor. Los dos importan. Este artículo explica cómo funciona la validación, por qué necesitas las dos y cuáles son los errores más comunes.
¿Qué es la validación?
La validación comprueba que los datos de un formulario cumplen tus requisitos. Los campos obligatorios tienen valor. Los campos de correo contienen una arroba. Los campos de teléfono contienen solo números. Los archivos subidos no superan el límite de tamaño.
Sin validación, entran datos erróneos en tu sistema. Tu backend falla. Tu servicio de correo rechaza mensajes. Pierdes tiempo limpiando datos sucios.
La validación ocurre en dos sitios: en el cliente (en el navegador, antes del envío) y en el servidor (en tu servidor, después del envío). Las dos son necesarias.
Validación en el cliente
El navegador puede comprobar los datos del formulario antes de enviarlos. HTML tiene atributos de validación integrados. JavaScript también puede validar.
Validación con HTML
<input type="email" required> valida que el campo tenga valor y que parezca un correo. El navegador muestra un mensaje de error si el usuario intenta enviar un formulario no válido.
Los atributos de validación de HTML incluyen required, para que el campo deba tener valor; min/max, para mantener los números dentro de un rango; minlength/maxlength, para exigir un número de caracteres; pattern, para ajustarse a expresiones regulares; y type, para validar el tipo de campo. Por ejemplo, type="email" comprueba el formato y type="number" rechaza lo que no sea numérico.
La validación con HTML funciona al instante sin necesidad de JavaScript, ofrece buenos mensajes de error del navegador y adapta el teclado del móvil al tipo de campo. Sus desventajas son que los mensajes de error del navegador son genéricos y a veces poco claros, que no se pueden personalizar sin JavaScript y que cada navegador muestra mensajes distintos.
Validación con JavaScript
Para tener más control, valida con JavaScript usando function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } y form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. La validación con JavaScript te permite escribir reglas propias, mostrar mensajes de error personalizados y validar los campos mientras el usuario escribe, en tiempo real. Entre sus desventajas están que necesita JavaScript (no es fiable para la seguridad), que requiere más código que mantener y que puede mostrar errores antes de que el usuario termine de escribir si validas en el evento input.
Validación en el servidor
Cuando se envía el formulario, el servidor vuelve a comprobar los datos. Aquí es donde está la seguridad de verdad.
Nunca te fíes de la validación en el cliente. Alguien puede desactivar JavaScript. Alguien puede interceptar la petición y modificar los datos. Alguien puede usar curl u otra herramienta para enviar datos erróneos sin pasar por tu formulario.
La validación en el servidor es la única protección que tienes. No es opcional.
Cuando el servidor recibe el envío del formulario, comprueba que los campos obligatorios estén presentes, valida el formato del correo, del teléfono y de las URL, comprueba que los números estén dentro de los rangos esperados, verifica que los archivos subidos sean del tipo y tamaño correctos, asegura que los datos no sean demasiado largos y sanea los datos para evitar ataques de inyección. Si la validación falla, envía una respuesta de error para que el formulario no se procese y se indique al usuario qué ha fallado. La validación en el servidor es más lenta porque el usuario tiene que esperar la respuesta, pero es fiable y segura, así que hazla siempre.
Cuándo usar cada tipo de validación
La validación en el cliente es para la experiencia de usuario. Avisa al usuario al momento si algo va mal. No tiene que enviar el formulario para descubrir que un correo no es válido.
La validación en el servidor es para la integridad de los datos y la seguridad. Garantiza que los datos erróneos nunca entren en tu sistema.
Usa las dos. La validación en el cliente, para la rapidez y la respuesta inmediata. La validación en el servidor, para la protección y la seguridad.
Errores comunes de validación
Validar solo en el cliente
Alguien desactiva JavaScript y tu validación desaparece. Alguien usa curl para enviar datos erróneos por POST y tu validación nunca se ejecuta. Acabas con basura en tu base de datos.
Valida siempre en el servidor. La del cliente es un extra.
Validar con demasiada rigidez
Tu validación de correo es tan estricta que fallan correos reales. Tu validación de teléfono solo acepta el formato de EE. UU. y rechaza números internacionales. Tu campo de nombre rechaza guiones, apóstrofos y otros caracteres válidos.
Prueba tu validación con datos reales. Pide a usuarios de otros países que la prueben. Haz las reglas de validación lo más permisivas posible sin dejar de detectar los datos erróneos.
No mostrar mensajes de error claros
"Entrada no válida". ¿Qué es lo no válido? ¿Qué campo? ¿Qué debe hacer el usuario?
Los mensajes de error tienen que ser concretos: "El correo debe tener entre 5 y 254 caracteres". "El teléfono debe tener 10 dígitos". "La contraseña debe contener al menos un número".
Muestra el error junto al campo que lo causó. No lo escondas en una lista resumen donde el usuario tenga que buscarlo.
Validar datos sensibles en el cliente
No pases números de tarjeta de crédito ni contraseñas por la validación del cliente. No los muestres en la consola del navegador. No los registres en logs.
Valida los datos sensibles solo en el servidor, por HTTPS.
No validar los archivos subidos
Alguien sube un archivo de 100 megabytes. Tu servidor se queda sin espacio. Alguien sube un archivo ejecutable. Tu servidor pilla un virus.
Valida el tipo y el tamaño del archivo en el servidor. Comprueba que el archivo es realmente del tipo que dice ser. No te fíes solo de la extensión ni del tipo MIME.
Validación en tiempo real o al enviar
La validación en tiempo real comprueba cada campo mientras el usuario escribe. El usuario ve un mensaje de error al instante si introduce algo incorrecto. Puede corregirlo en el momento.
Desventaja: si muestras los errores demasiado pronto, el usuario se frustra. Muestra los errores solo cuando el usuario sale del campo (en el evento blur), no mientras sigue escribiendo.
La validación al enviar comprueba todo cuando se envía el formulario. El usuario rellena todo el formulario y luego ve todos los errores a la vez.
Desventaja: el usuario tiene que volver atrás y corregir errores cuando ya ha enviado el formulario. Eso interrumpe el flujo.
Mejor práctica: valida en blur (cuando el usuario sale de un campo) para dar respuesta en tiempo real. Valida al enviar como comprobación final. Muestra todos los errores a la vez si falla alguno.
Validación según el tipo de campo
Validación de correo electrónico
La validación completa de un correo es compleja (la RFC 5322 tiene 60 páginas), así que, en la mayoría de los casos, comprueba que el valor contiene una arroba y un dominio usando const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Así detectas la mayoría de los correos no válidos sin ser tan estricto que fallen correos reales.
Validación de teléfono
El formato del teléfono varía según el país. El formato de EE. UU. es (123) 456-7890, el del Reino Unido es +44 20 7946 0958 y en Alemania se usa +49 30 123456. Acepta el formato internacional, elimina en el servidor los caracteres no numéricos y guarda el teléfono como texto y no como número, para conservar los ceros iniciales que hay en algunos países.
Validación de contraseña
Una buena contraseña es larga (al menos 12 caracteres) y difícil de adivinar. No exijas caracteres especiales ni mezcla de mayúsculas y minúsculas, porque esas reglas frustran a los usuarios y no mejoran la seguridad. Buenos requisitos de contraseña son al menos 12 caracteres y evitar patrones comunes (como "123456" o el nombre del usuario). Usa un medidor de seguridad de la contraseña para mostrar al usuario lo fuerte que es la suya.
Validación de fechas
Comprueba que la fecha sea futura o pasada, según convenga. Un formulario de inscripción a un evento debe rechazar fechas pasadas. Un formulario de fecha de nacimiento debe rechazar fechas futuras.
Cómo gestiona WEMASY la validación de formularios
Los formularios de WEMASY incluyen validación en el cliente integrada (campos obligatorios, formato de correo, etc.) para dar respuesta inmediata. Cuando se envían los formularios, los servidores de WEMASY vuelven a validar todos los datos antes de procesarlos. Así los usuarios reciben respuesta rápida y tus datos quedan protegidos.
Consulta las funciones de validación de tu plan de WEMASY.