Entrada (esquema .proto)

Salida (muestra JSON)

Qué hace esta herramienta

Tienes un esquema de Protocol Buffers y necesitas un ejemplo JSON de cómo se ve uno de esos mensajes — para un fixture de prueba, un ejemplo de OpenAPI, una respuesta gRPC simulada, lo que sea. Escribir a mano una forma JSON desde un archivo .proto largo es tedioso y propenso a errores. Este conversor lee el esquema, toma el último message declarado (el típico tipo "exterior") y emite un objeto JSON que coincide campo por campo.

La salida usa los valores por defecto oficiales de proto3: cadena vacía para string y bytes, 0 para tipos numéricos, false para bool, [] para repeated, {} para map, y la constante de enum con valor cero para campos enum. Los mensajes anidados se expanden recursivamente. Los enteros de 64 bits salen como cadenas JSON para coincidir con la especificación de mapeo JSON de proto3 — no puedes meter int64 en un Number de JS sin perder precisión.

Todo ocurre localmente en tu navegador — sin subir el .proto, sin enviar el esquema a un servidor, sin llamadas a IA. Solo un parser hecho a mano que maneja directivas syntax/package/import, comentarios (de línea y de bloque), bloques anidados de message y enum, oneof, map<K, V>, repeated, optional, y opciones de campo (que se leen pero se ignoran). Si necesitas un runtime completo estilo protobufjs, eso es otro problema — pero para "dame una forma JSON a partir de este esquema", esto es más rápido.

Cómo usarla

Tres pasos. El JSON de salida está listo para pegar en un fixture, un bloque de ejemplo o el cuerpo de una petición.

Pega tu esquema .proto

Suelta el esquema en el editor de la izquierda. syntax = "proto3"; arriba está bien pero es opcional — al parser le da igual. Comentarios, declaraciones de package y sentencias import se saltan limpiamente. Si tienes varios mensajes, el parser usa el último message de nivel superior (el típico tipo exterior/compuesto) como raíz.

¿Quieres convertir un mensaje distinto? Mueve el mensaje que te interesa al final del archivo. El esquema puede incluir tipos anidados, enums y bloques oneof — todos se resuelven.

Pulsa Convertir

Haz clic en el botón verde Convertir. El parser tokeniza el esquema, construye un árbol de mensajes y recorre el mensaje raíz emitiendo defaults de proto3 para cada campo. Los mensajes anidados se expanden inline. Los campos repeated producen un array de un elemento como pista de la forma del elemento — los arrays vacíos no mostrarían la estructura.

Usa el JSON

Copia el resultado en tu fixture de pruebas, tu bloque de ejemplo de OpenAPI, tu mock de gRPC-Web o donde necesites una forma de petición/respuesta. Las claves coinciden exactamente con los nombres de campo del .proto — pásalo a camelCase después si tu codegen lo hace así.

Cuándo te ahorra tiempo de verdad

Mockear respuestas gRPC en tests

Tu handler de servicio devuelve una respuesta Protobuf. El test unitario necesita un fixture JSON que coincida con la forma del mensaje. Pega el <code>.proto</code>, coge el JSON y déjalo en tu carpeta de fixtures. Se acabó escribir a mano 30 campos y olvidarse uno.

Ejemplos OpenAPI para un gRPC-gateway

¿Usas grpc-gateway o similar para exponer servicios Protobuf como REST? Cada operación necesita un ejemplo JSON. Convierte cada mensaje .proto en un esqueleto JSON y pégalo bajo la clave example de tu spec.

Punto de partida para JSON Schema

Quieres validar peticiones JSON que cumplan un contrato <code>.proto</code>. Convierte primero a una muestra JSON, pásala a una herramienta de JSON-Schema-desde-muestra y tienes un esquema inicial en segundos.

Rellenar cuerpos de petición en clientes API

¿Probando una API gRPC con HTTP transcoding en Postman o curl? Pega el .proto, copia el esqueleto JSON al cuerpo de la petición y rellena los valores que realmente quieras enviar.

Preguntas comunes

¿Se envía mi esquema .proto a algún sitio?

No. El parseo ocurre completamente en tu navegador vía JavaScript. Nada de tu esquema — nombres de mensajes, nombres de campos, rutas de package — sale de tu máquina. Abre DevTools y mira la pestaña Network mientras pulsas Convertir. Cero peticiones.

¿Maneja proto2 además de proto3?

En su mayoría. El parser maneja tokens de sintaxis proto2 como required y optional, pero los valores de salida usan defaults de proto3 (que es lo que especifica el mapeo JSON de proto3). Si tienes un archivo proto2 con defaults explícitos vía [default = ...], esos defaults no se aplican a la salida.

¿Cómo elige qué mensaje convertir?

Usa el último message de nivel superior declarado en el archivo. En esquemas reales el tipo exterior/compuesto suele declararse después de sus dependencias, así que cuadra con lo que quieres. Si elige el equivocado, reordena el archivo para que el mensaje que quieres quede al final.

¿Por qué los valores int64 son cadenas en la salida?

Porque JSON solo tiene doubles IEEE-754, que pierden precisión por encima de 2^53. El mapeo JSON oficial de proto3 exige que int64, uint64, fixed64, sfixed64, sint64 se codifiquen como cadenas JSON. Seguimos esa convención.

¿Y oneof, map y repeated?

Los tres funcionan. Los campos oneof se parsean como campos normales (el JSON incluirá todos en lugar de elegir uno — normalmente borras los que no quieres). map<K, V> emite un objeto {} vacío. repeated emite un array de un solo elemento mostrando la forma del elemento — puedes duplicarlo o borrarlo según tus datos reales.

¿Sigue los imports?

No. Las sentencias import se reconocen y se saltan. Los tipos de mensaje cross-file se resuelven a null en la salida. Si necesitas resolución entre archivos, pega los mensajes relevantes de los archivos importados en la misma entrada.

¿Cómo de grande puede ser un esquema?

Decenas de miles de líneas, sin problema. Todo es local, así que no hay subida, ni rate limit, ni latencia de red.

Herramientas relacionadas

Si trabajas con Protobuf, JSON y esquemas, estas combinan bien:

Conversor Protobuf a JSON