Repáralo ahora
- Suelta el archivo
- La reparación ocurre en local
- Descarga el resultado
De dónde salen las capturas PNG — y dónde se rompen
Toda la vida de una captura es capturar → escribir en disco → (normalmente) autosincronizar → pegar o compartir. El daño casi siempre entra en uno de los tres últimos pasos, y cuál de ellos deja una huella que puedes reconocer.
- Windows. PrtScn pone la imagen solo en el portapapeles: no se guarda nada hasta que pegas y usas Guardar como, así que un cuelgue la pierde por completo. Win+PrtScn y la Herramienta Recortes escriben un
.pngde verdad enPictures\Screenshots, y esa carpeta a menudo está redirigida a OneDrive. Cuando OneDrive empieza a subir una captura en cuanto aparece, un reinicio o un cierre de sesión a mitad de la subida puede dejar un archivo truncado: el clásico resultado de "la parte de arriba de la imagen está bien, la de abajo es gris". - macOS. ⌘⇧3/4/5 guarda un PNG (a menudo de tipo de color 6, RGBA, porque las capturas de ventana conservan una esquina transparente) en el Escritorio de forma predeterminada. Si tu Escritorio está en iCloud Drive, se aplica el mismo truncamiento a mitad de sincronización. Forzar el cierre de la interfaz de captura o de la miniatura flotante antes de que la escritura se vuelque también puede dejar el archivo cortado.
- Android. Las capturas van a parar a
DCIM/ScreenshotsoPictures/Screenshotsy se respaldan en Google Photos. El caso frágil es una captura con desplazamiento o de "capturar más": el sistema une varios fotogramas en un único PNG muy alto, y si ese paso de composición se interrumpe, el resultado puede quedar malformado en lugar de simplemente corto. - Pegada y vuelta a descargar. Este es el caso único de las capturas, porque son el archivo que la gente suelta directamente en Slack, Discord, Teams o una herramienta de tickets. Esos servicios a menudo recodifican al subir; descarga el resultado y cualquier daño previo queda ahora grabado en píxeles nuevos, o el archivo que guardaste es en realidad una vista previa HTML renombrada como
.png. - Enviada por un puente en modo texto. Una captura empujada a través de un cliente FTP dejado en modo ASCII, una vieja pasarela de correo o un script que la reescribió como texto cambia cada
0D 0Apor un0Asuelto (o al revés). La firma del PNG está deliberadamente construida para detectar justamente esto, y cuando la sustitución es consistente se revierte byte a byte.
Fíjate en el patrón: el fallo dominante de las capturas no es una corrupción exótica, es un guardado o una sincronización que se detuvo pronto. Eso es buena noticia para la recuperación, porque un archivo corto todavía contiene píxeles reales hasta el corte.
Por qué las dimensiones de una captura son de las recuperables
El único daño que impide abrir una captura pero se arregla a la perfección es un IHDR estropeado: la cabecera de 13 bytes que guarda la anchura y la altura. Ponlas a cero y ningún decodificador puede reservar un lienzo, así que Fotos o Vista Previa sencillamente rechazan el archivo. Pero IHDR, como todo chunk PNG, lleva un CRC-32 que se calculó cuando los números eran correctos, lo que significa que la geometría correcta se puede obtener por fuerza bruta: probar pares candidatos de anchura/altura, recalcular el CRC del chunk para cada uno y detenerse cuando coincide con el valor almacenado. (La mecánica completa de ese CRC y del chunk que protege está en la página del error de CRC de PNG.)
Las capturas hacen esa búsqueda casi trivial, porque sus dimensiones no son arbitrarias: se agrupan en una corta lista de resoluciones de pantalla. Una captura de Windows es muy probablemente de 1920×1080, 2560×1440 o 3840×2160; un teléfono tiene un tamaño de panel conocido como 1080×2400 o 1179×2556; y una captura Retina de macOS es la resolución del búfer de respaldo, es decir, el tamaño en puntos duplicado: una captura a pantalla completa de un MacBook Pro de 14 pulgadas es de 3024×1964, y una de 16 pulgadas, de 3456×2234. El chunk pHYs que suele llevar una captura registra esa densidad de píxeles, así que una captura Retina "@2×" hasta te dice su propia escala. Una búsqueda de geometría que sería lenta en una imagen cualquiera se resuelve en un puñado de intentos en una captura, porque la respuesta es casi siempre una resolución estándar.
Qué vuelve — y qué probar antes de reparar
Como el fallo habitual de una captura es un archivo corto, el resultado habitual es un parcial honesto: el PNG escribe sus filas de arriba abajo dentro de un único flujo comprimido continuo, así que una captura truncada se decodifica limpiamente hasta donde terminan los bytes, y la herramienta reescribe un cierre válido para que un visor acepte lo que sobrevivió. Las filas por debajo del corte nunca se escribieron, así que ninguna herramienta puede devolverlas; un daño que cae dentro del flujo en lugar de al final se lleva todas las filas por debajo. (Por qué ese flujo no puede resincronizarse —y por qué un golpe a mitad de flujo es permanente— se explica en la página del error de CRC de PNG.)
Pero antes de reparar, una captura suele tener una vía de escape más rápida que cualquier otro archivo dañado: prueba esto primero.
- ¿El contenido sigue en pantalla? Volver a hacer la captura es el arreglo más barato posible y te da un archivo impecable. Hazlo antes que nada si puedes.
- En Windows, PrtScn la mantiene en el portapapeles. Si el archivo guardado está roto pero no has copiado nada desde entonces, pega (Ctrl+V) en Paint o Fotos y usa Guardar como para crear un PNG nuevo: la copia del portapapeles es independiente del archivo corrupto.
- Comprueba la otra copia de una captura autosincronizada. Si el archivo local se truncó a mitad de la subida, la copia de OneDrive / iCloud / Google Photos puede estar completa, o al revés. Compara los tamaños de archivo; suele ganar la más grande y más reciente. Descarga la versión de la nube de nuevo en vez de fiarte del marcador de posición sincronizado.
- ¿La miniatura flotante de macOS sigue visible? Haz clic en ella para reabrir la captura y vuelve a exportarla antes de que desaparezca: esa copia en memoria no ha pasado por la escritura fallida.
Cuando nada de esto sirva, suelta el archivo arriba: el recorrido de chunks, las comprobaciones de CRC y la decodificación del flujo se ejecutan como código normal en la pestaña de tu navegador, y puedes abrir la pestaña Red para confirmar que salen 0 bytes, lo cual importa cuando la captura muestra un saldo bancario, un chat privado o una contraseña.
Qué puede y qué no puede reparar
Puede reparar
- Una captura truncada por una carpeta de subida automática (OneDrive / iCloud / Google Photos) que pilla el guardado a medio escribir: las filas escritas antes del corte se decodifican de vuelta como píxeles reales
- Anchura/altura de IHDR a cero o revueltas, recuperadas rápido porque las dimensiones de una captura son casi siempre una resolución de pantalla estándar
- Un chunk cuyo CRC-32 almacenado ya no coincide con datos por lo demás intactos: se recalcula el CRC y el archivo valida con cero pérdidas
- Corrupción por saltos de línea / modo texto (CR-LF ↔ LF) de una transferencia en modo ASCII o de un puente de chat que reescribió el archivo como texto
- Un marcador de final IEND ausente o malformado en un archivo cuyos datos de imagen están por lo demás completos
No puede reparar
- Las filas por debajo del corte en una captura truncada: esos píxeles nunca se escribieron y ninguna herramienta puede inventarlos
- Las filas de imagen por debajo de un golpe a mitad de flujo en IDAT: el flujo comprimido no puede resincronizarse, así que todo lo posterior es ruido
- Una captura que un servicio de chat o un editor recodificó tras el daño: los píxeles erróneos ya están grabados
- Una captura con desplazamiento o de 'capturar más' cuya unión falló tan gravemente que no se escribió ningún fotograma completo
- Un archivo que se lee como 0 bytes o todo ceros: no hay imagen que reconstruir (eso es recuperación de datos, no reparación)
Si una reparación falla, te decimos por qué (datos que faltan frente a estructura dañada), y nunca se te cobra por una reparación fallida.