DEV Community

Cover image for showDirectoryPicker: la API de Chrome que lee y escribe carpetas locales
lu1tr0n
lu1tr0n

Posted on • Originally published at elsolitario.org

showDirectoryPicker: la API de Chrome que lee y escribe carpetas locales

Una API del navegador llamada showDirectoryPicker permite que un sitio web pida permiso para leer y escribir una carpeta completa de tu disco. No es una promesa a futuro: ya funciona en Chrome, Edge y otros navegadores basados en Chromium, y está habilitando una generación de aplicaciones local-first que viven en una pestaña pero trabajan con tus archivos reales.

El detonante de esta conversación fue un experimento sencillo: un visor de fotos al estilo del viejo Aperture de Apple, construido entero en el navegador y capaz de mover imágenes entre carpetas de tu propio sistema de archivos. Sin servidor, sin nube y sin subir nada.

TL;DR

  • window.showDirectoryPicker() da a una web acceso de lectura y escritura a una carpeta local elegida por el usuario.- Llegó en Chrome 86 (octubre de 2020), dentro de la File System Access API; antes se llamaba Native File System API.- Solo funciona en navegadores Chromium (Chrome, Edge, Opera). Firefox y Safari no lo soportan en 2026.- Exige un gesto del usuario y un contexto seguro (HTTPS o localhost), y bloquea carpetas sensibles del sistema.- Los handles se guardan en IndexedDB para reabrir la misma carpeta en futuras sesiones sin repetir el diálogo.- Habilita editores de fotos, video y notas que trabajan con archivos reales del disco, no con copias en la nube.- El Origin Private File System (OPFS), parte de la misma API, sí funciona en Safari y Firefox para almacenamiento privado.

Qué es showDirectoryPicker y qué cambia

Durante años, la relación entre una página web y tu disco fue deliberadamente limitada. Un <input type='file'> te dejaba subir una copia de un archivo, y un enlace de descarga te devolvía otra copia a la carpeta de descargas. El navegador nunca tocaba el original. Esa frontera existía por seguridad, pero también condenaba a las aplicaciones web a ser huéspedes incómodos: todo lo que tocaban terminaba en un servidor o en una copia aislada.

showDirectoryPicker rompe ese molde. Cuando el usuario hace clic en un botón, la web invoca window.showDirectoryPicker() y el navegador muestra un diálogo nativo para elegir una carpeta. Si el usuario acepta, la página recibe un FileSystemDirectoryHandle que representa esa carpeta y permite recorrerla, abrir sus archivos y, con permiso adicional, modificarlos en el sitio. La aplicación ya no trabaja con copias: trabaja con tus archivos.

El ejemplo que disparó esta conversación lo deja claro. Un desarrollador, nostálgico por la interfaz de Aperture, pidió a un asistente de IA que recreara ese estilo usando showDirectoryPicker. El resultado fue un visor parecido a Lightroom, pero corriendo en una pestaña: podías crear carpetas, mover fotos entre ellas y todo ocurría directamente en tu sistema de archivos.
Editores que viven en el navegador pero trabajan con tus archivos reales.

Cómo funciona: del clic al archivo

El flujo es asíncrono de principio a fin y arranca siempre con una interacción del usuario. El método devuelve una promesa que se resuelve con el handle de la carpeta:

// Debe ejecutarse dentro de un evento de usuario (clic)
const dirHandle = await window.showDirectoryPicker();

// Recorrer las entradas de la carpeta
for await (const [nombre, handle] of dirHandle.entries()) {
  console.log(nombre, handle.kind); // 'file' o 'directory'
}
Enter fullscreen mode Exit fullscreen mode

Cada entrada es un FileSystemFileHandle o un FileSystemDirectoryHandle. Para leer el contenido de un archivo pedimos su handle y obtenemos un objeto File estándar, idéntico al que devolvería un input tradicional:

const fileHandle = await dirHandle.getFileHandle('notas.md');
const file = await fileHandle.getFile();
const texto = await file.text();
console.log(texto);
Enter fullscreen mode Exit fullscreen mode

Escribir es donde la API se vuelve realmente distinta. Un flujo de escritura (WritableStream) vuelca los datos al archivo y, al cerrarlo, el navegador realiza un reemplazo atómico para evitar archivos corruptos a medio escribir:

const fileHandle = await dirHandle.getFileHandle('nuevo.md', { create: true });
const writable = await fileHandle.createWritable();
await writable.write('# Hola desde el navegador');
await writable.close(); // se confirma el cambio en disco
Enter fullscreen mode Exit fullscreen mode

El diagrama resume el camino completo, desde el clic hasta la lectura o la escritura:

graph LR
  A["Clic del usuario"] --> B["showDirectoryPicker()"]
  B --> C["Navegador pide permiso"]
  C -->|"Concedido"| D["FileSystemDirectoryHandle"]
  C -->|"Denegado"| E["AbortError"]
  D --> F["Leer y escribir archivos"]
Enter fullscreen mode Exit fullscreen mode

Permisos, seguridad y contexto seguro

Dar a una web acceso a tu disco suena peligroso, y por eso la especificación está rodeada de barreras. Primero, showDirectoryPicker solo funciona en un contexto seguro: la página debe servirse por HTTPS o desde localhost. Segundo, la llamada exige activación del usuario; no se puede disparar el diálogo desde un script al cargar la página. Tercero, el navegador bloquea carpetas sensibles, como las del sistema operativo o los directorios raíz.

El permiso de escritura es independiente del de lectura. Conviene verificarlo y, si hace falta, pedirlo de forma explícita:

async function asegurarEscritura(handle) {
  const opciones = { mode: 'readwrite' };
  if ((await handle.queryPermission(opciones)) === 'granted') return true;
  return (await handle.requestPermission(opciones)) === 'granted';
}
Enter fullscreen mode Exit fullscreen mode

⚠️ Ojo: el permiso no es eterno. Al recargar o cerrar la pestaña, el navegador suele exigir que el usuario vuelva a conceder acceso a la carpeta, incluso si guardaste el handle. Diseña la app para volver a pedir permiso sin perder el contexto.

Para probar en local, cualquier servidor estático sobre localhost cuenta como contexto seguro. La misma orden sirve en los tres sistemas:

# Windows (PowerShell), macOS y Linux con Python 3
python -m http.server 8000

# Alternativa con Node.js en cualquier sistema
npx serve .
Enter fullscreen mode Exit fullscreen mode

Contexto e historia

La idea no nació ayer. La API empezó su vida con el nombre Native File System API, luego pasó a File System Access API y hoy buena parte de sus piezas se estandarizan en la File System API de la WHATWG. Chrome la habilitó de forma estable en su versión 86, lanzada en octubre de 2020, y desde entonces Edge y Opera la heredaron por compartir el motor Chromium.

Junto a showDirectoryPicker viajan dos hermanos: showOpenFilePicker() para abrir archivos sueltos y showSaveFilePicker() para guardar con un diálogo nativo de tipo «Guardar como». Y hay una cuarta pieza, más silenciosa pero importante: el Origin Private File System (OPFS), un sistema de archivos privado y de alto rendimiento que cada origen web obtiene mediante navigator.storage.getDirectory(). A diferencia de showDirectoryPicker, el OPFS no toca tus carpetas visibles y sí cuenta con soporte en Safari y Firefox.
showDirectoryPicker y el OPFS resuelven necesidades distintas.

Datos y cifras: soporte entre navegadores

El gran asterisco de showDirectoryPicker sigue siendo la compatibilidad. En 2026 el panorama es nítido:

  • Chrome y Edge — soporte completo desde la versión 86 (2020).- Opera — soportado por compartir el motor Chromium.- Firefox — sin soporte para showDirectoryPicker; solo implementa el OPFS.- Safari — sin soporte para elegir carpetas del disco; también limitado al OPFS.

Para audiencias amplias, sobre todo en LATAM donde el parque de navegadores es heterogéneo, la regla de oro es la detección de características antes de usar la API:

if ('showDirectoryPicker' in window) {
  // Ruta moderna: acceso real a carpetas
} else {
  // Plan B: input type=file y descargas, o el OPFS
}
Enter fullscreen mode Exit fullscreen mode

💭 Clave: aunque showDirectoryPicker no esté disponible en todos los navegadores, el OPFS sí lo está. Una app puede usar la carpeta real cuando se puede y caer al almacenamiento privado cuando no.

Impacto y análisis: la era local-first

El verdadero cambio que trae showDirectoryPicker no es técnico, es de modelo mental. Durante la última década, casi toda aplicación seria empujó tus datos a la nube: tus notas, tus fotos y tus documentos vivían en el servidor de alguien más. El movimiento local-first propone lo contrario: que el dato viva en tu máquina, que la app sea solo una ventana sobre él y que la nube, si existe, sea opcional y para sincronizar, no para encerrar.

Esta API encaja exactamente en esa filosofía. Una aplicación de notas puede pedir acceso a tu carpeta de Markdown y editarla sin intermediarios: tú eres el dueño de los archivos, no un proveedor que puede cerrar mañana. Lo mismo aplica a editores de fotos, gestores de proyectos o entornos de desarrollo. Ya existen editores de video que usan WebGPU dentro del navegador; combinarlos con acceso real al sistema de archivos abre la puerta a herramientas profesionales que cargan los originales del disco sin una sola subida.

El beneficio de privacidad es directo. Si los archivos nunca salen de tu equipo, no hay copia en un servidor que filtrar, indexar o vender. Y el de rendimiento también: leer un proyecto de varios gigabytes desde el disco local es órdenes de magnitud más rápido que descargarlo. Sumá la generación de interfaces con asistentes de IA, como en el experimento que originó esta historia, y el costo de prototipar una app de escritorio dentro del navegador se desploma.

Qué sigue

El futuro inmediato de showDirectoryPicker depende de dos frentes. El primero es la estandarización: mientras la pieza viva solo en Chromium, los desarrolladores seguirán tratándola como una mejora progresiva y no como una base sólida. El segundo es la presión del ecosistema; cuanto más útiles sean las apps local-first, más difícil será para Firefox y Safari ignorar la función, aunque hoy prioricen el OPFS por sus garantías de privacidad.

Mientras tanto, el patrón ganador es claro: detectar la capacidad, usar la carpeta real cuando exista, persistir el handle en IndexedDB para una experiencia continua y degradar con elegancia al OPFS o a los inputs clásicos cuando no. Las PWA empaquetadas como apps de escritorio son el caso de uso que más se beneficia, porque combinan instalación, atajos nativos y acceso a archivos en un solo paquete.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Funciona showDirectoryPicker en Firefox o Safari?

No. En 2026 solo lo implementan los navegadores basados en Chromium (Chrome, Edge y Opera). Firefox y Safari ofrecen únicamente el Origin Private File System, que no da acceso a tus carpetas visibles.

¿Es seguro darle a una web acceso a mis archivos?

La API está diseñada con barreras: requiere HTTPS, exige un clic del usuario, muestra un diálogo nativo donde eliges exactamente qué carpeta compartir y bloquea directorios sensibles del sistema. El acceso se limita a lo que concedés y se puede revocar.

¿Se puede recordar la carpeta entre sesiones?

Sí. El FileSystemDirectoryHandle es serializable y puede guardarse en IndexedDB. Al volver, recuperás el handle, aunque por seguridad el navegador suele pedir que confirmes el permiso de nuevo con requestPermission().

¿Qué diferencia hay entre showDirectoryPicker y el OPFS?

showDirectoryPicker accede a carpetas reales y visibles de tu disco que el usuario elige. El OPFS es un almacenamiento privado por origen, invisible en el explorador de archivos y pensado para datos internos de la app; además está disponible en más navegadores.

¿Necesito un servidor para probarlo?

Necesitás un contexto seguro. Sirve la página por HTTPS o desde localhost; un servidor estático local basta. Abrir el HTML con file:// no funciona.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Top comments (0)