Por qué Excel elimina los ceros a la izquierda de tus códigos CSV y cómo conservarlos (Guía 2026)

Diagnóstico en 30 segundos: el archivo está bien, Excel adivinó mal

Lo primero que hay que establecer cuando tus códigos pierden sus ceros es si los datos están dañados o solo mal interpretados, porque los dos casos tienen soluciones muy distintas, y la solución equivocada puede convertir un problema de visualización en una pérdida real de datos. Esta es la prueba de 30 segundos. Abre el mismo archivo en un editor de texto plano, el Bloc de notas en Windows o TextEdit en modo de texto plano en un Mac. Si los códigos muestran todos sus ceros allí, 00123, 02138, 07477, tus datos están intactos y solo la visualización de Excel está mal. El archivo en el disco contiene los caracteres correctos, y Excel cambió su significado cuando abrió el archivo. Ese es el caso habitual, y todas las soluciones de esta guía parten de él.

La segunda pista es qué valores cambiaron. Si las palabras corrientes, los números cortos y la puntuación se ven bien, pero los códigos con ceros a la izquierda los perdieron, los identificadores largos perdieron sus últimos dígitos y los números grandes se muestran en notación científica, estás ante una adivinanza de tipos, no ante un problema de delimitador ni ante datos corruptos. Un problema de delimitador mete filas enteras en una sola columna. Los datos corruptos desordenan todo o eliminan filas. La adivinanza de tipos es quirúrgica: cambia exactamente los valores que parecen números y deja todo lo demás intacto. Si 00123 se convirtió en 123, 02138 se convirtió en 2138 y un identificador de 16 dígitos termina en un cero que antes no tenía, Excel trató texto como números, y eso te dice tanto la causa como la solución.

La tercera comprobación decide si el rescate todavía es posible. Si el editor de texto también muestra los valores recortados, el archivo en sí ya se volvió a guardar después de la conversión, y los ceros pueden haber desaparecido ya de esa copia. No entres en pánico todavía y, sobre todo, no vuelvas a guardar sobre el original. La sección de rescate más adelante en esta guía cubre exactamente este caso, incluida la única situación en la que los dígitos son realmente irrecuperables: cuando un identificador largo se truncó a 15 dígitos, los dígitos perdidos desaparecieron de esa copia y solo los datos de origen pueden regenerarlos. Hasta que lo hayas comprobado, deja el archivo original intacto, trabaja sobre una copia y nunca guardes un archivo convertido sobre el bueno.

Por qué Excel adivina: un archivo CSV no incluye tipos

Para entender por qué esto sigue ocurriendo, necesitas un dato sobre el formato CSV: un archivo CSV es texto plano sin ningún encabezado que diga qué valores son números, cuáles son texto y cuáles son fechas. Un archivo de hoja de cálculo lleva sus tipos de celda consigo. Un archivo CSV no lleva ni tipos ni formato. Son solo caracteres, comas y saltos de línea. Cuando un programa lo abre, el programa debe decidir qué significa cada valor, y los distintos programas deciden de forma distinta. Google Sheets y Python conservan los valores CSV como texto salvo que se les indique lo contrario, por eso el mismo archivo se ve correcto en ellos. Excel, cuando haces doble clic en un archivo CSV, adivina: todo lo que parece un número se convierte en un número, todo lo que parece una fecha se convierte en una fecha, y no comprueba si esa adivinanza fue correcta.

Esa adivinanza es todo el problema. Un número, por definición, no tiene ceros a la izquierda: el número 123 y el código 00123 son el mismo número, pero no son el mismo código. Un código postal, una referencia, un identificador de empleado o un prefijo telefónico no es una cantidad. Es una etiqueta formada por dígitos, y sus ceros a la izquierda forman parte de la etiqueta, exactamente igual que las letras de una palabra. Excel no lo sabe. Ve dígitos, aplica su regla de número y elimina los ceros, porque para un número real los ceros no aportan información. La misma lógica explica la segunda víctima: los números de Excel conservan solo 15 dígitos significativos, así que un identificador de 16 dígitos o más ve sus dígitos sobrantes sustituidos por ceros. El archivo no cambió. El lector cambió el significado de los caracteres.

También explica por qué este problema aparece tan a menudo con archivos convertidos desde JSON. JSON sí distingue tipos: la cadena "00123" y el número 123 son valores distintos, y una conversión de JSON a CSV escribe la cadena como los caracteres 00123. La conversión es correcta. La apertura no coincide. El conversor de esta página, por ejemplo, se probó con una muestra que contenía los códigos 00123 y 00456, los códigos postales 02138 y 07477 y un identificador de pedido de 18 dígitos, y produjo cada valor byte a byte idéntico en el CSV, sin trucos de comillas y sin dígitos perdidos. Saber que el desajuste está en el paso de apertura, no en el paso de conversión, te dice dónde corregirlo: en la importación, antes de que Excel adivine, como muestran las siguientes secciones.

Tres formas en las que la adivinanza destruye datos, y cómo distinguirlas

La adivinanza de tipos destruye datos de tres formas distintas, y distinguirlas importa porque solo algunas son reparables. La primera es la pérdida de ceros a la izquierda: 00123 se convierte en 123, 02138 se convierte en 2138. Los dígitos que quedan son correctos, pero el código ya está mal: un código postal que perdió su cero apunta a otro lugar, una referencia que perdió sus ceros no coincidirá con el sistema del almacén, y un escáner de códigos de barras puede rechazar el código acortado. La segunda es el truncamiento de precisión: cualquier identificador de más de 15 dígitos pierde su parte final. Un identificador de cuenta de 16 dígitos como 1234567890123456 se convierte en 1234567890123450, mostrado como 1.23457E+15. Los últimos dígitos no están ocultos, están sustituidos por ceros, y el identificador ahora apunta a otro registro o a ningún registro.

La tercera forma es más sutil, y atrapa a quienes creen haber resuelto el problema. La visualización en notación científica parece pérdida de datos, pero todavía no lo es. Un valor mostrado como 1.23E+15 puede conservar todos sus dígitos por debajo si está dentro del límite de 15 dígitos, y ensanchar la columna o cambiar el formato los muestra de nuevo. Pero si el valor supera los 15 dígitos, la visualización es honesta: los dígitos realmente desaparecieron. La prueba es la barra de fórmulas. Haz clic en la celda y lee la barra de fórmulas, no la visualización de la celda. Si la barra de fórmulas muestra el valor completo, solo la visualización necesita arreglo. Si la barra de fórmulas muestra el valor truncado, los datos en sí cambiaron, y solo la sección de rescate puede ayudar. Nunca confíes solo en la visualización de la celda para códigos e identificadores.

El bloque de código siguiente muestra los resultados exactos, producidos al ejecutar el conversor real de esta página sobre una muestra de tres filas. La salida CSV es byte a byte idéntica a la entrada JSON para cada código, lo que demuestra que el conversor no es el culpable. La parte derecha muestra lo que Excel hace con esos mismos valores al hacer doble clic, que es el comportamiento que corrige esta guía. Observa el patrón: el conversor conserva, Excel adivina, y en la adivinanza se pierde cada dígito.

CSV file (from this page converter, verified):\nsku,zip,name,orderId\n00123,02138,Widget A,\n00456,07477,Widget B,\n00078,,Widget C,123456789012345678\n\nWhat Excel shows on double-click:\nsku -> 123, 456, 78 (leading zeros dropped)\nzip -> 2138, 7477 (leading zeros dropped)\norderId -> 1.23457E+17, stored as 123456789012345000 (last 3 digits replaced with zeros)

Observa lo que demuestra la tabla: no falta nada en el archivo, y falta todo en la vista de Excel. Por eso la solución de importación funciona de forma tan completa. Cuando le dices a Excel que una columna es Texto antes de cargar, guarda los mismos caracteres sin ninguna conversión, y cada código vuelve a ser él mismo, sin ediciones, sin buscar y reemplazar, y sin introducir datos. Si tu archivo coincide con este patrón, sáltate la sección de mitos y ve directamente a la solución de importación. No tienes un archivo dañado. Tienes un archivo mal interpretado.

Cuatro soluciones que no funcionan, y por qué la gente sigue intentándolas

Antes de las soluciones que funcionan, conviene apartar las cuatro que no funcionan, porque cada una hace perder tiempo y una de ellas empeora las cosas. La primera es entrecomillar los valores en el CSV. Muchas guías afirman que escribir "00123" entre comillas protege los ceros. No es así, en Excel. Excel elimina las comillas durante la importación y luego aplica la misma adivinanza de número al valor interior, así que "00123" se convierte en 123 exactamente igual que 00123 sin comillas. Las comillas controlan cómo se tratan las comas dentro de un valor, no cómo Excel asigna el tipo al valor. Si alguien te vendió un conversor que entrecomilla códigos para protegerlos, las comillas protegen las comas, no los ceros.

La segunda es dar formato Texto a la columna después de abrir el archivo. Esto cambia cómo se tratan las entradas futuras, pero no restaura dígitos que ya se perdieron cuando Excel leyó el archivo. Los ceros se descartaron en el momento de lectura, y el formato no puede inventar caracteres que ya no están. La tercera es el formato personalizado 00000, que rellena la visualización hasta cinco dígitos. Funciona solo como visualización, para códigos de longitud fija, y solo cuando los dígitos sobrevivieron: 123 se muestra como 00123, pero el valor guardado sigue siendo 123, así que cualquier exportación escribe 123, y cualquier búsqueda frente al código real falla. Peor aún, falla en silencio con códigos de longitud variable, porque un código de seis dígitos rellenado a cinco dígitos no cambia, y un código de cuatro dígitos rellenado a cinco gana un cero que nunca tuvo.

La cuarta es el truco del apóstrofo, escribir un apóstrofo delante del código, como en una celda escrita como 00123 con un apóstrofo delante. Eso funciona para valores que escribes a mano, porque el apóstrofo le dice a Excel que guarde la entrada como texto. No funciona para una importación CSV, porque el apóstrofo pasa a formar parte del contenido del archivo: una celda CSV que contiene un apóstrofo seguido de dígitos se importa como un valor de texto que empieza literalmente por un apóstrofo, lo que rompe búsquedas y exportaciones. Reserva el apóstrofo para entradas escritas a mano, y usa la solución de importación para archivos. Saber qué soluciones fallan te ahorra la trampa más habitual de todas: creer que el problema está resuelto porque la visualización parece correcta, mientras los valores guardados siguen estando mal.

Solución 1: importa el archivo y asigna el tipo Texto a las columnas de códigos

Esta es la solución que conviene probar primero, porque no cambia nada de tu sistema, nada del archivo, y funciona con cualquier CSV sea cual sea su delimitador o su codificación. En lugar de hacer doble clic en el archivo, abre primero Excel y luego importa el archivo mediante la importación guiada, donde eliges tú mismo el tipo de cada columna. La vista previa del cuadro de importación te muestra de inmediato si elegiste bien: los códigos se muestran con sus ceros en la vista previa exactamente como aparecerán en la hoja. Si la vista previa sigue mostrando códigos recortados, todavía no has cambiado nada, y puedes ajustar los tipos de columna antes de cargar.

• ▸Abre un libro en blanco en Excel. No hagas doble clic en el archivo CSV.
• ▸Ve a Datos, luego a Desde texto/CSV, y selecciona tu archivo.
• ▸En el cuadro de vista previa, revisa el delimitador y el origen del archivo, y haz clic en Transformar datos en lugar de Cargar, para abrir el editor de Power Query.
• ▸En el editor de Power Query, busca el paso automático Tipo cambiado y elimínalo, porque ese paso es donde ocurre la adivinanza de número.
• ▸Selecciona cada columna de códigos, códigos postales, referencias, identificadores, prefijos telefónicos, y asigna el tipo de datos Texto.
• ▸Haz clic en Cerrar y cargar. Los códigos llegan como texto, con cada cero a la izquierda y cada dígito intactos.

Convierte esto en tu forma habitual de abrir archivos CSV, no solo en tu medida de rescate. Hacer doble clic es una adivinanza sobre el delimitador, la codificación y el tipo de cada columna. Importar es una decisión sobre los tres, y la decisión lleva alrededor de un minuto más. En un Mac, la misma ruta funciona mediante Datos, luego Desde texto, con los tipos de columna asignados en el paso de importación. Las herramientas que leen CSV como texto plano, como el módulo csv de Python, nunca adivinan, por eso un archivo que parece roto en Excel se lee correctamente en un script. Esa diferencia es en sí misma un diagnóstico: si un script muestra los ceros y Excel no, el archivo está bien y Excel adivinó mal.

Solución 2: desactiva la conversión automática de datos de Excel (Microsoft 365 y Excel 2024)

Si abres archivos CSV todos los días, importar cada vez se hace pesado, y la solución duradera es cambiar lo que Excel adivina por defecto. Las versiones recientes de Excel, Microsoft 365, Excel 2024 y sus equivalentes para Mac, incluyen un ajuste llamado conversión automática de datos, en Archivo, luego Opciones, luego Datos. Enumera las conversiones que Excel aplica por su cuenta, incluida la eliminación de ceros a la izquierda de texto numérico, el truncamiento de números a 15 dígitos y la conversión de cadenas de letras y números que parecen fechas o notación científica. Desmarca las conversiones que no quieras, y Excel dejará esos valores como texto en aperturas futuras, incluidas las aperturas con doble clic.

Dos advertencias antes de confiar en este ajuste. Primera, cambia solo el comportamiento futuro. No repara celdas que ya se convirtieron, y no restaura dígitos que ya se perdieron. Un archivo que abriste la semana pasada sigue conteniendo los valores convertidos en el libro, y solo una importación nueva desde el archivo original devolverá los códigos. Segunda, el ajuste vive en tu equipo, no en el archivo. Un colega que abra el mismo archivo en un equipo con el ajuste por defecto seguirá viendo códigos recortados, y un archivo que envíes no lleva ninguna protección consigo. Trata el ajuste como una comodidad para tu propio equipo, y trata la solución de importación como el método fiable para archivos que compartes. Las guías compañeras sobre el problema de una sola columna y el problema de codificación cubren las otras dos adivinanzas que Excel hace al abrir, delimitador y codificación, y están enlazadas en las guías relacionadas más abajo.

Solución 3: para archivos que produces, conserva los códigos como texto en el origen

Si produces el CSV, la solución más sólida es hacer que los datos de origen sean inequívocos antes de que lleguen a Excel. En JSON, eso significa conservar los códigos como cadenas, no como números: la cadena "00123" se convierte en los caracteres 00123, mientras que el número 123 se convierte en 123, sin ceros que conservar. Esta es una decisión sobre los datos de origen, no un ajuste del conversor, porque ningún conversor puede inventar ceros que el número de origen nunca tuvo. Si tu sistema de origen ya guarda un código postal como número, los ceros desaparecieron antes de la conversión, y solo el sistema de origen puede restaurarlos, por ejemplo volviendo a exportar el código como una cadena de ancho fijo.

Para valores que ya perdieron sus ceros pero tienen una longitud fija, existe una reconstrucción legítima: la función TEXTO. Si cada código de una columna tiene cinco dígitos, =TEXTO(A2;"00000") reconstruye la visualización y el valor de texto a partir del número recortado, porque los dígitos que faltan son todos ceros y su cantidad es conocida. Copia los resultados y pégalos como valores para fijarlos. Pero esto funciona solo cuando la longitud es fija y el único daño son ceros a la izquierda perdidos. No puede reconstruir un identificador largo truncado, porque los dígitos perdidos no eran ceros, eran dígitos desconocidos sustituidos por ceros, y ninguna fórmula puede adivinarlos. Si tus identificadores varían en longitud o superan los 15 dígitos, no rellenes, regenera desde el origen.

Rescata un archivo que ya se guardó con los códigos recortados

Hasta ahora cada solución ha supuesto que el archivo en el disco sigue siendo correcto y que solo la vista de Excel está mal. Pero a veces la versión recortada ya se guardó, y la pregunta pasa a ser si los códigos originales todavía se pueden recuperar desde la copia guardada. La respuesta depende de exactamente qué hizo el guardado, y hay dos casos que distinguir. En el primer caso, el archivo en el disco sigue conteniendo los caracteres originales, y solo la visualización del libro está mal. Ese es el caso que detecta la prueba del editor de texto: el editor muestra los ceros, así que no se perdió nada, y la Solución 1 repara la vista. En el segundo caso, el archivo en el disco contiene ahora los propios valores recortados, porque alguien lo abrió en Excel, vio los códigos acortados y lo volvió a guardar como CSV, escribiendo los valores convertidos en el archivo.

El segundo caso solo es recuperable en circunstancias limitadas. Si cada código tiene una longitud fija y el único daño son ceros a la izquierda perdidos, la función TEXTO de la Solución 3 los reconstruye, porque se sabe que los caracteres que faltan son ceros. Trabaja sobre una copia, nunca sobre la única versión, y comprueba el resultado en un editor de texto antes de volver a abrirlo en Excel. Si el daño es un truncamiento de precisión, un identificador de más de 15 dígitos con su parte final sustituida por ceros, los dígitos originales desaparecieron de esa copia. Ninguna decodificación, formato o fórmula puede recuperar dígitos que fueron sustituidos por marcadores, porque los marcadores no contienen información sobre qué dígitos sustituyeron. En ese caso, deja de reparar la copia y regenera el archivo desde su origen: vuelve a exportarlo desde la base de datos, la herramienta o el JSON del que provino, y esta vez ábrelo con la Solución 1. Y hagas lo que hagas, conserva la copia dañada aparte hasta que el archivo regenerado quede comprobado. Eliminar la única copia antes de verificar el reemplazo es como un problema recuperable se convierte en un conjunto de datos perdido.

Qué significa esto para los archivos de este conversor

El conversor de esta página produce exactamente el tipo de archivo del que trata esta guía, así que conviene declarar su comportamiento con claridad. La descarga conserva los códigos exactamente como los contiene el JSON. Eso se verificó con el código real, no se supuso: el motor de conversión se ejecutó sobre una muestra de tres filas con los códigos 00123, 00456 y 00078, los códigos postales 02138 y 07477 y el identificador de pedido de 18 dígitos 123456789012345678, y produjo cada valor byte a byte idéntico en el CSV, con los códigos sin comillas porque no contienen ningún delimitador, y el identificador largo intacto. Así que si tu archivo convertido muestra códigos recortados en Excel, la conversión no dañó nada. El archivo es correcto, y Excel adivinó los tipos al hacer doble clic.

Eso te da dos opciones limpias para archivos convertidos. La primera es la ruta de importación: abre el archivo descargado con Datos, luego Desde texto/CSV, haz clic en Transformar datos, asigna el tipo Texto a cada columna de códigos, y carga. Los códigos se leerán correctamente, y no has cambiado nada del archivo, así que sigue siendo válido para cualquier otra herramienta. La segunda es el ajuste de conversión automática de la Solución 2, para tu propio equipo. No vuelvas a convertir los datos para corregir un problema de visualización por adivinanza de tipos, y no pases la salida convertida por una hoja de cálculo para volver a guardarla, porque ese viaje de ida y vuelta puede introducir exactamente los desajustes de delimitador, codificación y tipo que esta guía y sus compañeras existen para prevenir. Corrige la apertura, no los datos.

Un detalle más del conversor importa aquí. El conversor te permite elegir el delimitador antes de descargar, y esa elección es independiente de la adivinanza de tipos. Un archivo puede tener el delimitador correcto y los códigos recortados al mismo tiempo, o los códigos correctos y el delimitador equivocado, o ambas cosas mal a la vez. Si tu archivo convertido se abre en una sola columna y los códigos se ven mal, corrige ambos ajustes en la misma importación: elige el delimitador que escogiste en el momento de conversión, y asigna el tipo Texto a las columnas de códigos. La guía compañera sobre el problema de una sola columna cubre la mitad del delimitador en detalle, y la guía de codificación cubre la mitad de los caracteres, y ambas están enlazadas en las guías relacionadas más abajo.

Lista de prevención: exporta códigos para que nadie tenga que corregirlos

La adivinanza de tipos es un desajuste entre quien escribe y quien lee, así que la prevención significa hacer que quien escribe declare qué son los valores, de una forma que el lector respete. Repasa esta lista cuando produces un CSV, y la próxima persona que lo abra no necesitará esta guía. Primero, conserva los códigos como cadenas en el origen. Si tus datos contienen códigos postales, referencias o identificadores, guárdalos como texto en el sistema de origen, porque un tipo número elimina los ceros antes de que ocurra cualquier exportación. Segundo, si el público usa Excel, diles cómo abrir el archivo: una nota de una línea que diga que hay que importar con las columnas de códigos asignadas a Texto previene todo el problema, y no cuesta nada incluirla con el archivo.

Tercero, nunca vuelvas a guardar un archivo rescatado sobre el original hasta haber verificado el rescate en un editor de texto. Un guardado desde Excel reescribe tipos, delimitadores y codificación con los valores por defecto de Excel, lo que puede reintroducir el desajuste para el siguiente lector, o convertir un problema de visualización en una pérdida real de datos. Cuarto, cuando recibas un archivo, ábrelo primero en un editor de texto si algo se ve raro, y confirma los códigos antes de dejar que cualquier hoja de cálculo lo sobrescriba. Y quinto, conserva los datos de origen. Un CSV es una instantánea aplanada, no los datos en sí, así que si un rescate sale mal, el origen te permite exportar de nuevo limpiamente en lugar de reparar una copia dañada. La mayoría de historias de terror con códigos terminan con alguien descubriendo demasiado tarde que el CSV dañado era la única copia. No dejes que ese sea tu archivo.

Guías relacionadas

• El archivo CSV se abre en una sola columna en Excel: por qué pasa y cómo corregirlo (Guía 2026) →
• Por qué tu CSV muestra caracteres extraños en Excel y cómo corregir la codificación (Guía 2026) →
• Cómo convertir JSON a CSV: 3 métodos fiables (guía 2026) →
• Por qué Excel cambia las fechas de tu CSV e intercambia el día y el mes, y cómo evitarlo (Guía 2026) →
• Por qué guardar tu CSV en Excel lo cambia y cómo mantener el original a salvo (Guía 2026) →
• Por qué tu CSV es demasiado grande para Excel y qué hacer en su lugar (Guía 2026) →

Preguntas frecuentes