Lo que Chrome guarda por sitio web—y cómo borrarlo todo de una vez
Cada vez que visitas un sitio web, Chrome escribe datos en tu computadora en nombre de ese sitio. Algunos son obvios: cookies, sesiones de inicio de sesión. Muchos no lo son: contadores de uso, flags de prueba, marcadores de "ya vi este modal", asignaciones de pruebas A/B, estado de asistentes de configuración, flags de incorporación completada.
El sitio no necesita saber quién eres para recordar lo que has hecho. Solo escribe en localStorage o IndexedDB, y Chrome lo mantiene ahí indefinidamente, hasta que tú lo borres.
El punto clave: Mucho de lo que los sitios web "recuerdan" de ti no está guardado en sus servidores. Está en tu navegador. Eso significa que puedes borrarlo sin tocar tu cuenta. El modo Debug de VertiTab lo hace en un clic.
Qué guarda Chrome por cada sitio
Al visitar cualquier dominio, varios sistemas de almacenamiento independientes funcionan simultáneamente:
| Tipo de almacenamiento | Para qué lo usan los sitios | ¿Sobrevive la recarga? |
|---|---|---|
localStorage | Contadores de uso, preferencias, flags de prueba, toggles | ✓ Para siempre |
IndexedDB | Estado de la app, datos offline, contenido estructurado | ✓ Para siempre |
sessionStorage | Estado de formularios de varios pasos, progreso de asistentes | Hasta cerrar el tab |
| Cache Storage | Assets offline, recursos del Service Worker | ✓ Para siempre |
| Service Workers | Servir versiones de la app en caché | ✓ Hasta deregistración |
| Cookies | Sesiones, seguimiento, flags de expiración de prueba | Hasta fecha de vencimiento |
Lo importante es la última columna. Estos datos sobreviven la recarga forzada, el vaciado de caché e incluso el reinicio del navegador. Persisten hasta que se eliminan explícitamente.
Por qué los sitios guardan "límites" en el almacenamiento del cliente
Detrás de la mayoría de los prompts "prueba X veces gratis, luego inicia sesión" hay este mecanismo:
- Usas una función sin iniciar sesión
- El sitio incrementa un contador en
localStorage:{ trialUsed: 1 } - En la próxima visita, lee ese contador para decidir si mostrar el paywall
- Todo el proceso ocurre en JavaScript ejecutándose en tu navegador; ningún servidor interviene
Este patrón es común en herramientas de IA con prompts gratuitos limitados, editores de documentos con límite de páginas, conversores de video con límite de archivos, correctores gramaticales con cuota de palabras, y numerosas herramientas SaaS en modo de prueba.
El mismo mecanismo aparece en contextos no comerciales: sitios de noticias que cuentan artículos leídos en el mes con localStorage (paywalls blandos), plataformas de tutoriales que recuerdan qué capítulos completaste, y flujos de incorporación que solo muestran el tour la primera vez.
Qué restablece realmente borrar los datos del sitio
Después de usar el modo Debug para limpiar un sitio, esto es lo que se restablece:
Para usuarios comunes:
- Contadores de uso de prueba en localStorage o cookies
- Flags de "ya has visto esta oferta/modal"
- Contadores de artículos leídos en paywalls blandos
- Flags de supresión de modales ("no volver a mostrar")
- Asignaciones A/B (recibirás una nueva variante en la próxima carga)
Para desarrolladores:
- Estado de aplicación obsoleto tras cambiar el esquema de la base de datos
- Service Worker sirviendo un bundle antiguo en caché
- Registros de IndexedDB corruptos por una migración fallida
- Artefactos de token de sesiones de prueba anteriores
Ambos grupos están reseteando el mismo almacenamiento subyacente. La diferencia es solo el propósito.
Lo que borrar datos del sitio no puede resetear
No puede eludir:
- Seguimiento de uso en el servidor (si el sitio registra tu IP o huella digital del dispositivo en su backend)
- Límites basados en cuenta (las cuotas de usuarios con sesión iniciada están en el servidor)
- Límites de prueba vinculados a métodos de pago o verificación telefónica
Puede resetear:
- Cualquier límite implementado exclusivamente en almacenamiento del cliente sin validación del servidor
- Estado de sesión que el sitio no persistió en el servidor
- Preferencias y flags almacenados localmente
Muchos sistemas de prueba usan solo almacenamiento del cliente porque es más sencillo para usuarios anónimos. Pero sistemas mejor diseñados validan en el servidor. La única manera de saberlo es intentarlo.
Cómo usar el modo Debug
Por pestaña (uso puntual):
- Clic derecho en cualquier pestaña del panel lateral de VertiTab
- Seleccionar Activar modo Debug
- Elegir qué tipos de almacenamiento limpiar
- Opcionalmente marcar "Aplicar a este sitio" para configuración permanente
Por sitio (persistente):
- Configuración de VertiTab → Configuración de sitios
- Buscar el sitio por hostname
- Activar el toggle Modo Debug
- Clic en Configurar para preferencias de almacenamiento
Una vez activo, el ícono 🐛 aparece junto a la pestaña. Un clic borra todo y recarga. Sin DevTools.
Opciones configurables: Cache Storage, localStorage, sessionStorage, IndexedDB, Service Workers, Cookies, Historial
Mantener la sesión pero borrar datos de uso
Limpiar todas las cookies en un sitio donde tienes sesión iniciada te desconectará. Para resetear datos de uso pero mantener el login, usa la lista de exclusión de cookies.
Carga todas las cookies actuales de la pestaña y marca cuáles conservar: tokens de autenticación, tokens CSRF, identificadores de sesión. El resto se elimina normalmente. Los patrones de exclusión admiten solo nombre (session_id) y entradas con dominio (api.example.com:token).
Cuándo usar cada opción
| Situación | Qué hacer |
|---|---|
| JS/CSS no actualiza tras deploy | Recarga forzada es suficiente |
| El sitio "recuerda" que usaste la prueba | Modo Debug |
| Siempre la misma variante A/B | Modo Debug |
| El flujo de incorporación no reaparece | Modo Debug |
| Estado de la app roto tras actualización | Modo Debug |
| No sabes qué está causando el problema | Modo Debug; es el punto de partida seguro |
Casos de uso
Restablecer pruebas gratuitas sin login — Muchas herramientas de IA, editores de documentos, conversores y demos de SaaS permiten probar sin registrarse. Tras 2–3 usos aparece "regístrate para continuar". Ese contador vive en localStorage o cookies. Borrarlo te hace pasar por nuevo visitante.
Paywalls blandos de artículos — Los sitios de noticias suelen contar los artículos leídos en el mes con localStorage. Esto es diferente a un paywall duro basado en login. Borrar los datos del sitio resetea el contador.
Repetir flujos de incorporación — Las guías de producto se suprimen con un flag hasCompletedOnboarding: true en localStorage. Borrarlo permite experimentar el flujo de nuevo, útil para evaluar productos o testear UX.
Bugs de estado en SPAs — Esquema cambiado, la app falla con datos antiguos. Debug Mode limpia registros de IndexedDB para testear la migración desde cero.
Service Worker que no actualiza — SW sirviendo código viejo. Debug Mode desregistra y limpia su caché en un paso.
QA regresión — Estado limpio reproducible con un clic, sin navegar DevTools.
Preguntas frecuentes
P: ¿Por qué muchos sitios guardan "límites" en localStorage en vez del servidor?
R: Para usuarios anónimos, el almacenamiento del cliente no necesita infraestructura backend. Es más fácil de implementar, sin costo de servidor, sin identificación de usuario. La contrapartida es que es fácil de borrar—por eso los productos más maduros migran eventualmente a validación en servidor.
P: ¿Borrar datos del sitio me desconectará?
R: Depende de la configuración. Si borras cookies y tu sesión está en una cookie, sí. Usa la lista de exclusión para preservar cookies de autenticación.
P: ¿Funciona para límites basados en cuenta?
R: No. Si el sitio valida el uso en el servidor, borrar datos del cliente no ayuda.
P: ¿Necesito DevTools abierto?
R: No. Funciona en cualquier momento, sin importar si DevTools está abierto.
P: ¿El modo Debug es premium?
R: Sí, requiere suscripción premium de VertiTab.
P: ¿Configuraciones distintas por sitio?
R: Sí. La configuración se almacena por hostname de forma independiente.
Lectura relacionada: