Convertidor de carpeta local a texto

Convertir una carpeta local a texto: tu base de código en un solo archivo, sin subirla

Apunta esto a una carpeta de tu máquina y recibes un único archivo de texto: el árbol de directorios al principio y después todos los archivos que hayas seleccionado, cada uno separado por una cabecera con su ruta. Lo llames como lo llames — juntar una base de código en un archivo, concatenar el código fuente, fusionar un directorio en un documento — la idea es esa. Es el formato que mejor maneja un LLM, porque el modelo ve al mismo tiempo la forma del proyecto y el contenido, y puede razonar sobre cómo se relaciona un archivo con otro.

Es gratis, no hay registro y no hay nada que instalar. Elige una carpeta, desmarca lo que el modelo no necesita y exporta el proyecto como un único archivo de texto que puedes pegar donde quieras.

La parte que a casi todo el mundo le importa: no se sube nada. En este circuito no hay servidor. Tus archivos se leen en el navegador, se ensamblan en memoria y se te devuelven. Si has estado evitando los conversores online porque la base de código es de un cliente, está bajo acuerdo de confidencialidad o sencillamente no es tuya como para pegarla en un servicio de terceros, esa objeción aquí no aplica; y la siguiente sección explica exactamente por qué, porque «confía en nosotros, es seguro» no es una respuesta que nadie deba aceptar.

Cómo funciona sin subir nada un conversor privado de código a texto

Los navegadores modernos pueden leer archivos del disco sin mandarlos a ninguna parte. Cuando eliges una carpeta, el navegador le entrega a la página una lista de manejadores de archivo. Cada uno se lee con la API estándar FileReader, que decodifica los bytes a una cadena en la memoria de la propia pestaña. El árbol de directorios, el recuento de tokens, la concatenación: todo eso ocurre en JavaScript ejecutándose en tu máquina. No hay fetch, ni XHR, ni endpoint de API, ni llamada de analítica de terceros que lleve el contenido de los archivos. Abre la pestaña de red de tu navegador mientras conviertes y la verás quedarse vacía.

Ese mecanismo tiene efectos colaterales útiles más allá de la privacidad:

• Funciona sin conexión. Una vez cargada la página, desconecta el cable de red. La conversión sigue funcionando. Útil en una máquina aislada o en una red corporativa cerrada a cal y canto.
• Sin límites de subida ni de tasa. No hay cuota de API que agotar, porque no hay API. El único techo es la memoria de tu navegador y tu paciencia.
• Funciona con código que nunca se commiteó. Una rama de pruebas, un experimento sin seguimiento, una carpeta que jamás ha visto un git init: el conversor de repositorios de GitHub a texto no puede tocar nada de eso, porque lee de la API de GitHub. Este lee del disco, así que tu situación con el control de versiones le da exactamente igual.
• No se guarda nada. Cierra la pestaña y el estado desaparece: no hay historial que purgar ni cuenta que tenga una copia de tu código.

Tres formas de meter un proyecto

Usa el selector de directorios para navegar hasta una carpeta, o arrastra la carpeta directamente desde Finder o el Explorador a la zona de soltado. Las dos recorren el árbol de forma recursiva, así que obtienes el proyecto completo, subdirectorios anidados incluidos, y no solo el primer nivel.

También puedes soltar un archivo ZIP y se descomprime en el navegador, cómodo cuando alguien te ha enviado un proyecto por correo o cuando prefieres no extraerlo. Una distinción que conviene conocer: usa esta página cuando el comprimido contenga un proyecto de código, porque lo que quieres es el árbol de directorios y las cabeceras de ruta por archivo. Si es un montón de documentos — informes, hojas de cálculo, PDF —, encajan mejor ZIP a texto o ZIP a Markdown, que sacan el contenido legible de cada documento en lugar de tratar los archivos como código fuente.

Cualquier IDE, cualquier editor: solo quiere una carpeta

No hay ningún complemento que instalar ni ninguna extensión que aprobar, porque esto no se integra con tu editor en absoluto. Coge un directorio. Da igual que ese directorio sea un workspace de VS Code, un proyecto de IntelliJ IDEA o PyCharm, una solución de Visual Studio, un módulo de Android Studio, un proyecto de Xcode, un workspace de Eclipse o una carpeta que solo has abierto en Neovim: son los mismos archivos en el mismo disco. Apunta el selector ahí y ya está.

Vale la pena decirlo, porque «exportar mi proyecto de VS Code a un solo TXT» y «exportar un proyecto de IntelliJ a un archivo» son cosas que la gente le pregunta primero a su editor. Los editores suelen ser el sitio equivocado donde mirar. Exportan archivos, de uno en uno. Unos pocos tienen una extensión del marketplace que lo resuelve a medias, la mayoría no, y cada uno lo resuelve a su manera, así que una respuesta para un IDE deja de servir en cuanto cambias. La carpeta es el denominador común.

También es mejor jugada que comprimir el proyecto y mandarlo. Un comprimido está bien de desarrollador a desarrollador, pero un modelo de chat quiere texto, no un contenedor, y un revisor tiene que extraerlo antes de leer una sola línea. Un .txt consolidado se lee en línea: lo pegas en una conversación, lo adjuntas a un ticket, lo sueltas en un hilo de correo. Y si es a ti a quien te han mandado un ZIP, puedes soltarlo directamente en esta página en lugar de descomprimirlo antes.

Poda sin piedad antes de generar

Este es el paso que la gente se salta, y es el que decide si la salida sirve. En el árbol de casillas todo empieza marcado, lo que significa que por defecto estás a punto de incluir un montón de cosas que ningún modelo necesita ver.

Aquí hay algo que juega a tu favor. Si la carpeta contiene un .gitignore, se lee y se aplican sus reglas, incluidas las anidadas más adentro del árbol, acotadas a su propio directorio y saltándose las líneas de comentario. En un repositorio normal eso elimina discretamente a los peores infractores antes de que toques nada, porque lo que infla un volcado suele ser exactamente lo mismo que ya le dijiste a git que ignorara. El directorio .git se excluye siempre.

Aun así, no te apoyes solo en eso. Una carpeta sin .gitignore — un ZIP extraído, una entrega de un proveedor, un directorio que nunca fue un repositorio — no tiene ninguna de esas protecciones. Y hay muchas cosas ruidosas que están legítimamente versionadas en git. Repasa el árbol y desmarca:

• node_modules, vendor, .venv, site-packages. Los árboles de dependencias son enormes y nada de eso es código tuyo. Un node_modules sin podar puede ser por sí solo cientos de miles de tokens de código de otra gente. Ahogará el proyecto real y las respuestas del modelo derivarán hacia las tripas de las bibliotecas.
• Artefactos de build — dist, build, .next, target, out, informes de cobertura. Es tu propio código, minificado o transpilado, duplicado. Ruido puro.
• Lockfiles. package-lock.json, yarn.lock, poetry.lock, Cargo.lock. Miles de líneas de hashes que casi no llevan información semántica. Quédate con el manifiesto (package.json, pyproject.toml): esa es la parte que le dice al modelo con qué stack trabajas.
• Código generado y fixtures — salidas de protobuf, codegen de GraphQL, migraciones de base de datos, archivos grandes de seed o de snapshot.
• Cualquier cosa con secretos. No se transmite nada, pero el archivo de salida acabará tarde o temprano en una ventana de chat. Deja el .env fuera.

Los archivos binarios se gestionan por ti: las imágenes, las tipografías, los artefactos compilados y demás se filtran por extensión antes siquiera de llegar al árbol, y lo que se cuele lo pilla un escaneo de bytes nulos y se sustituye por un marcador breve en vez de volcarse como basura. Los archivos de más de 1 MB también reciben un marcador que indica su tamaño, lo que evita que un CSV despistado se coma todo tu presupuesto de contexto.

Hay además un interruptor para el árbol de directorios que va al principio de la salida: filtrado muestra solo lo que seleccionaste, completo muestra la estructura entera con tus selecciones marcadas. El completo es la mejor opción cuando preguntas por arquitectura, porque el modelo puede ver que existe un directorio tests/ aunque no lo hayas incluido. El filtrado es mejor cuando quieres al modelo concentrado en algo estrecho y nada más.

Cómo no salirse de la ventana de contexto

La salida generada viene con un recuento de tokens real, producido por la biblioteca gpt-tokenizer y no por una estimación de caracteres entre cuatro. Compáralo con tu modelo antes de pegar. Es un flujo de trabajo bastante mejor que pegar, esperar y recibir un error de longitud.

Orientación aproximada sobre cuánto mandar. Manda el proyecto entero cuando sea lo bastante pequeño para caber con holgura y tu pregunta sea arquitectónica: «dónde se aplica realmente la autenticación», «qué se rompería si cambio esta interfaz», «explícame el flujo de datos desde la petición hasta la base de datos». El modelo necesita la foto completa para responder eso con honestidad, y un volcado parcial produce conjeturas muy seguras sobre archivos que nunca vio.

Manda una porción cuando la pregunta sea local: un módulo más los tests que lo cubren, más los dos o tres archivos de los que importa. Menos contexto significa respuestas más afiladas y menos deriva, y normalmente sacarás mejores resultados de 5.000 tokens bien elegidos que de 200.000 indiscriminados.

Los monorepos exigen un enfoque deliberado. No conviertas la raíz del repositorio. Convierte un paquete cada vez, y si ese paquete depende de una biblioteca interna compartida, incluye junto a él la superficie pública de esa biblioteca. Si necesitas contexto entre paquetes, un buen truco son dos pasadas: una con el árbol completo y casi ningún archivo seleccionado — eso le da al modelo un mapa — y luego una segunda, cargada de archivos, sobre el paquete en el que estás trabajando de verdad.

¿Por qué no un cat o un script de shell?

Pregunta justa, y a veces la respuesta honesta es que sí deberías. Si quieres juntar tres archivos que ya conoces, cat auth.py models.py routes.py > out.txt es más rápido que abrir un navegador. Nadie intenta convencerte de lo contrario.

Donde deja de compensar es en el momento en que lo apuntas a un proyecto entero. Ejecuta find . -type f -exec cat {} + sobre un repositorio real y esto es lo que obtienes:

• Binarios en medio de tu código. PNG, tipografías, objetos compilados, una fixture SQLite despistada: todo decodificado como texto, todo mojibake. Y entonces empiezas a mantener una lista blanca de extensiones.
• El árbol de dependencias entero. node_modules, .venv, vendor, target y el contenido del propio .git. Excluir todo eso significa escribir expresiones de poda y mantenerlas al día para cada proyecto en el que trabajes. Aquí tu .gitignore ya describe exactamente eso, archivos anidados incluidos, y se aplica solo.
• Ni idea de cuánto ocupa. La concatenación te da bytes, no tokens, y dividir caracteres entre cuatro es una conjetura que falla en las dos direcciones. Descubres que no cabe cuando el modelo lo rechaza.
• El control selectivo cuesta más script. «Todo lo que hay bajo src menos el cliente de API generado, más los dos archivos de configuración de la raíz» es otro flag y otra regex. Un árbol de casillas hace eso en unos cuatro clics.
• Sin mapa al principio. La concatenación en bruto es un muro de texto sin cabecera de estructura, así que el modelo no puede saber dónde acaba un archivo y empieza el siguiente, ni qué aspecto tiene la organización del proyecto. Las secciones delimitadas por ruta y un árbol de directorios son casi todo lo que hace legible un volcado.

Todo esto se puede construir, y mucha gente lo ha construido. Es una tarde de scripting y después una herramienta pequeña que mantienes. La elección está en si quieres el script o quieres la salida.

Para qué lo usa la gente de verdad

• La base de código que acabas de heredar. Alguien se fue y ahora un servicio de 40.000 líneas es tuyo. Conviértelo, pégalo y pide los puntos de entrada, las abstracciones principales y las tres cosas que más sorprenderían a un mantenedor nuevo. Es una orientación más rápida que cualquier documento de traspaso que te vayan a dar.
• Documentación a partir del código real. Los README se pudren porque se escriben una vez. Genéralos desde el código que existe ahora mismo: resúmenes de arquitectura, resúmenes por módulo, una lista fiel de las variables de entorno que la aplicación lee de verdad.
• Tests para código sin tests. Incluye el módulo más un archivo de test existente como referencia de estilo. El modelo se ajusta a tu framework, a tus nombres y a tus patrones de fixtures en lugar de inventarse una convención de pruebas que no usas.
• Planificar migraciones y refactorizaciones. Componentes de clase a hooks, JavaScript a TypeScript, un ORM por otro. Un modelo que ve todos los puntos de llamada te da un plan real y no una lista genérica.
• RAG y embeddings. Un único archivo de texto limpio con secciones delimitadas por ruta es fácil de trocear por esos delimitadores y de meter en una base vectorial.

Cuando termines, copia la salida al portapapeles o descárgala como archivo .txt: vale la pena guardarla si vas a reutilizar el mismo contexto en varias conversaciones.

El código es solo la mitad del contexto

La mayoría de las preguntas reales sobre un proyecto también implican cosas que no son código fuente. La especificación vive en un PDF, el esquema en un JSON, la configuración en XML, los datos en un CSV. Conviértelos por separado y pégalos junto al volcado de tu base de código: PDF a Markdown para especificaciones y documentación de proveedores, Word a Markdown para documentos de requisitos, JSON a Markdown para payloads y esquemas de API, XML a Markdown para configuración heredada, CSV a Markdown para datos de ejemplo, y HTML a Markdown para páginas exportadas. Si prefieres no elegir formato, File2Txt acepta lo que le eches.

Preguntas frecuentes

¿Cómo convierto una carpeta a un archivo de texto?

Elige un directorio arriba y obtienes su árbol como una lista de casillas. Marca los archivos que quieras y exporta un único archivo de texto: primero la estructura de directorios y luego cada archivo bajo una cabecera con su ruta. Gratis, sin registro, sin nada que instalar.

¿Se sube mi código a un servidor?

No. En este circuito no hay servidor de ningún tipo. La carpeta se lee en el navegador, la salida se ensambla en el navegador y nada cruza la red: puedes abrir las herramientas de desarrollo y comprobarlo, o desconectarte de internet después de cargar la página y seguirá funcionando. Esa es la diferencia con el conversor de GitHub, que tiene que llamar a la API.

¿Es seguro convertir online el código de una empresa?

Esta página es la versión que responde a esa pregunta con mecánica en lugar de con una promesa: los archivos nunca salen de la máquina, así que no hay nada que tengas que confiarnos. Lo que sí sigue importando es lo que hagas después: pegar la salida en un modelo alojado se la envía a ese proveedor, así que consulta la política de tu organización y quita los secretos antes de hacerlo.

¿Puedo convertir un proyecto entero con subcarpetas?

Sí, se recorre el árbol completo y todos los niveles son seleccionables. Desmarcar una carpeta elimina todo lo que hay debajo de un clic, que es la forma de tirar node_modules o .git sin ir rebuscando entre los hijos. El contador de tokens se actualiza sobre la marcha para que veas el efecto al instante.

¿Qué navegadores pueden seleccionar una carpeta entera?

La selección de carpetas usa el atributo de subida de directorios que Chrome, Edge, Firefox y Safari llevan años admitiendo, así que cualquier navegador de escritorio actual funciona. El hueco está en el móvil: ni iOS ni Android exponen un selector de carpetas. En un teléfono, comprime el directorio y usa ZIP a texto.

¿Cuál es el límite de tamaño de archivo?

No hay subida, así que no hay límite de subida: la restricción es la memoria de tu máquina y cuánto texto puedas pegar de forma útil después en algún sitio. En la práctica el contador de tokens se convierte en el límite real mucho antes que el navegador. Un repositorio cuyo código útil ocupa menos de un megabyte cubre casi todos los proyectos una vez desmarcadas las dependencias.

El resto de la caja de herramientas

Si el código está alojado en lugar de en local, el conversor de GitHub a texto y el conversor de GitLab a texto hacen el mismo trabajo contra un repositorio remoto, privados incluidos con un token. Para documentación que solo existe en la web, Web2Txt convierte una URL en Markdown limpio: empareja una referencia de API extraída con tu código local y un asistente de programación verá los dos lados a la vez.

Hay más escrito en el blog si quieres profundizar: convertir una base de código en un archivo listo para LLM, un recorrido por el conversor de carpeta a texto, una guía para darle un repositorio entero a una IA, y la guía general de conversión de archivos a texto para todo lo que no es código.

Repo2Txt está desarrollado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.