Neatbo.

Local schemas and semantic data: Protobuf, Avro, JSON-LD, RDF and CRS

Inspect Protobuf with its schema, compare Avro resolution directions, process offline JSON-LD, canonicalize RDF and reproject GeoJSON with explicit CRS. Check limits and receiver handoff.

Choose the interpretation your receiving task needs

When you have bytes and their .proto, inspect the selected Protobuf message. When you have writer and reader schemas, compare Avro resolution directions. Byte inspection reads a specific message; schema compatibility asks whether two declarations can resolve in the chosen direction.

Use offline JSON-LD processing to expose term IRIs or compact expanded data with a supplied context. Use canonical RDF comparison to test whether complete N-Quads datasets are equivalent despite temporary blank-node labels. Use CRS reprojection when geometry coordinates must move between the explicitly supported longitude/latitude and Web Mercator pair. These are separate jobs; formatting JSON does not perform them.

Input contract and useful delivery
TaskSupplyKeep with the result
Inspect a Protobuf messageOriginal bytes, standalone proto2/proto3 and full message typeFinal values, presence/unknown wire report and unchanged original.bin
Compare Avro resolutionExplicitly labelled writer and reader JSON schemasBoth compatibility directions, underlying errors and the two schemas
Inspect JSON-LD termsDocument plus inline context or exact URL-to-local-context envelopeExpanded/compacted JSON-LD, base choice and context map
Compare RDF exportsTwo strict RDF 1.1 N-Quads datasetsBoth canonical N-Quads, algorithm and complete difference report
Reproject geometryStrict 2D GeoJSON and known source/target CRSReprojected GeoJSON, CRS/axis report and original metadata

Inspect Protobuf with the original schema and retain presence

Supply a binary file or strict hex/base64 text, paste the standalone proto2/proto3 schema in the secondary field and specify its full message path. In demo.Event below,087b120161 carries seq123 and payload byte a. Decoded output represents seq as decimal string "123" and payload as base64 "YQ==". No type is guessed, import fetched or service executed.

Read final decoded values and presence separately from defaults. A proto3 implicit zero can be omitted; optional and oneof zero values retain explicit presence. Singular submessage fragments merge before recursive final required checks. A later oneof member wins, while repeated fragments of the same message member merge. Unknown fields, wrong wire types and closed-enum unknown values retain original fragments; the complete binary stays available. Inspection JSON is not lossless re-encoding.

Declared groups, extensions, editions, services, external imports and features overrides are unsupported. Protected identifiers reject, as do explicit proto2 byte defaults and unsafe/nonfinite numeric schema defaults. Schema stays data, without user script or service execution; controlled internal decoder generation runs in a same-origin independent HTTP Worker without changing page CSP.

Standalone schema matching the example bytes
syntax = "proto3";
package demo;
message Event { int64 seq = 1; bytes payload = 2; }

Label the Avro writer and reader before reviewing both directions

The primary input is the writer schema; the secondary input is the intended reader. An int writer can promote into a long reader; the reverse cannot guarantee every long fits int. Valid incompatible schemas produce a complete false report. Invalid JSON or schema rejects. Forward/backward labels still require clearly identified participants.

A new reader field needs an appropriate default. Supported reader record/field aliases can resolve renames, and fullnames include namespace. Underlying resolutionError remains text rather than a fabricated exact field path. Named recursive schemas are bounded; datum, IDL and Schema Registry history/policy are not evaluated.

Pinned avsc5.7.9 requires union field defaults to match the first branch. Logical types and protected identifiers are unsupported. Removing a logicalType changes the question, so do not present the altered result as compatibility of the original schema. Resolution does not validate every business value constraint or registry policy.

Provide every JSON-LD context locally

Paste an object or array, choose expand or compact, and supply the secondary envelope with contexts and optional compactContext. Each mapped document must contain @context and its URL key must match the requested absolute HTTP(S) URL exactly. A missing mapping fails; the tool never requests the URL. Compaction requires a non-null compactContext.

For example, a context mapping name to https://example.com/name expands name:"Alice" to that IRI with @value:"Alice". An unbound property can disappear, and an empty expansion is valid. Check the term mapping before deciding that an empty result is a processing error. Set a document base explicitly for relative IRIs; the base of an imported document is not automatically inferred from its local filename.

Offline mapping envelope
{"contexts":{"https://example.com/context":{"@context":{"name":"https://example.com/name"}}},"compactContext":"https://example.com/context"}

Compare RDF datasets, then interpret the diff

Paste the right dataset and paste or open the left export. Both must be strict N-Quads, with absolute IRIs and supported RDF 1.1 terms. If your source is RDF/XML or Turtle, export it first. The parser retains named graphs, datatype and language meaning; repeated quads follow set semantics and language tags are normalized to lowercase.

Two lines that differ only in _:alice versus _:person can describe the same dataset. RDFC-1.0 with SHA-256 assigns a common canonical form. For unequal datasets, the displayed additions/removals compare their separately canonicalized line sets. A graph edit can change many blank-node labels, so the difference is not a minimal edit plan or a persistent node correspondence. Download both canonical files for review.

Make CRS and axis order explicit

The supported pair is EPSG:4326 longitude,latitude in degrees and EPSG:3857 easting,northing in meters. Select different source and target values. A six-digit coordinate does not establish its CRS; obtain that information from the source. Unknown CRS, 3D/M positions and coordinates outside the supported area reject.

At longitude120 and latitude30, Web Mercator is approximately [13358338.895192828,3503549.843504374] meters. Confirm one known point and reverse it within the stated numerical tolerance. GeoJSON geometry/ring/hole order and Feature IDs/properties are retained; metadata numbers keep their source tokens. Existing bbox/crs members reject so stale bounds cannot survive. Preserve those separately before deliberate removal. No UTM, datum/grid conversion or topology repair is supplied.

Use the stated budgets and recover from errors

These budgets are input and computation contracts, not evidence that a receiver accepts the download. Each preview shows at most200 rows/nodes while downloads contain the complete successful result. A failed run supplies no partial result.

Current supported limits
TaskInputAdditional budget
ProtobufBinary2 MiB / encoding text6 MiB; schema1 MiBWire and decoded20000values/depth32; total artifacts10 MiB
AvroWriter and reader schema1 MiB eachEach10000JSONvalues/depth32; complete direction report
JSON-LDDocument1 MiB and envelope1 MiB separatelyEach10000JSON values/depth32;32 mapped URLs/64loads; result10 MiB
RDF comparisonCombined2 MiB/10000parsed quadsBlank component256/deepiterations10000/10-second work deadline
CRS reprojection2 MiB/50000strict2D positionsGeometrydepth20; result10 MiB; latitude±85.0511287798066°
  • Retain originals and the exact context/CRS choices; reopen the downloaded result in the receiving application.
  • Fix a missing JSON-LD mapping under its exact URL, correct N-Quads syntax, or correct source CRS/axis order before rerunning.
  • When a work budget fails, partition only if the meaning of the dataset survives that partition; renaming an extension does not change support.

References

Tools in this category

Expand a tool to see its steps, options and supported formats, then open its workspace.

Schema-bound Protobuf message decoderInspect binary Protobuf with a supplied standalone proto2/proto3 schema and explicit message type, including 64-bit integers, field presence and unknown wire records.

Read message bytes when you have their original schema. The report separates final values, explicit presence, declared defaults and wire sightings, and keeps the original binary for verification.

Steps

  1. Select a binary file, or choose hex/base64 and paste encoded bytes.
  2. Paste the exact original .proto and fill the full message type.
  3. Review decoded values, presence, oneofs and unknown records; download the report and original bytes, then verify with the receiving schema.

Available options

Pasted text encoding
Hex · Base64
Full message type
demo.Event
Protect CSV cells in spreadsheets
On by default

Capabilities and limits

  • One binary file up to 2 MiB, or pasted hex/base64 text up to 6 MiB whose decoded bytes stay within 2 MiB. ASCII spaces, tabs and line breaks may separate encoding text. Hex has no0x prefix; base64 requires standard characters, correct padding and canonical padding bits. A selected file takes precedence. Zero bytes can represent a valid empty message.
  • Paste a standalone proto2/proto3 .proto in the secondary field, up to 1 MiB,10000 descriptor JSON values and depth 32. Supply the explicit full message path, such as demo.Event; no type guessing or fetched import. Editions, services, extensions, declared groups and features overrides are unsupported. Names/paths are limited to 4096 characters; protected segments including __proto__, constructor and prototype reject to prevent renaming or prototype issues.
  • Wire lengths, tags, varints, UTF-8 strings and recursion budgets are checked before decoding. Wire traversal is capped at depth 32/20000 entries, including containers and packed elements; final decoded JSON at 20000 values/depth 32. Singular message fragments merge before final recursive required checks. Oneof last values and duplicate map keys follow Protobuf semantics. Invalid schema, truncation or missing final required fields fail atomically.
  • Output uses original protobuf field names. Every 64-bit integer is a decimal string; bytes are base64; enums retain numbers with names/aliases alongside. Float NaN, Infinity and negative zero use explicit strings. Defaults are reported without injecting absent fields; proto3 implicit zero values can disappear from decoded while wire sightings remain. Explicit proto2 byte defaults and unsafe/nonfinite numeric schema defaults are unsupported. Proto 3 explicit defaults reject.
  • Unknown fields, wrong wire types of known fields and closed proto2 unknown enum values include exact original offset/length/base64. A packed closed-enum record contains its entire original packed field, possibly including known values. Wire sightings can describe subsequently overwritten or discarded values. Inspection JSON is not lossless re-encoding; original binary stays complete. Total successful artifact size is10 MiB; table previews200 fields, JSON/CSV are complete. Schema is data; no user scripts, services or downloaded code execute. Trusted internal library decoder generation runs only in a standalone same-origin HTTP Worker, retaining page CSP.
Open Schema-bound Protobuf message decoder →
Avro writer/reader schema compatibilityCheck both resolution directions between local Avro JSON schemas, including promotion, aliases, defaults and incompatible results.

Label the schema that wrote data and the schema expected by its reader. Review each resolution direction before accepting a field addition, rename or type change.

Steps

  1. Supply the original writer schema and intended reader schema.
  2. Review writer→reader first, then the reverse direction and any underlying resolution error.
  3. Confirm supported schema and business value constraints before downloading JSON or CSV.

Available options

Protect CSV cells in spreadsheets
On by default

Capabilities and limits

  • Writer schema: one UTF-8 file or pasted JSON; reader schema: secondary JSON input. Each is limited to 1 MiB,10000 JSON values and depth 32. A selected file takes precedence. Duplicate keys, nonfinite values and unsafe integers reject without rounding defaults.
  • Supports primitive, record, enum, fixed, array, map, union and named recursive schemas. Checks writer→reader and reader→writer separately, including full namespaces, reader aliases, defaults and numeric promotion. Fixed size is1..1048576; structural schema budget is10000 nodes/depth 32.
  • Pinned avsc5.7.9 requires a union field default to match its first branch; newer later-matching-branch defaults are unsupported. Every logicalType rejects. Protected identifier segments __proto__, constructor and prototype reject in names, namespaces, aliases, fields and enum symbols.
  • Reports schema resolution compatibility, without executing datum, IDL, registry policy, scripts or services, and without network requests. Only trusted library internal resolver generation runs inside a standalone same-origin HTTP Worker. Blob Worker and page codegen are blocked by production CSP. Underlying error text is not an invented exact field path. Both direction results and CSV are complete.
Open Avro writer/reader schema compatibility →
Offline JSON-LD expander and compactorExpand or compact JSON-LD 1.1 with inline contexts and a supplied local URL-to-context map, without fetching remote documents.

Inspect the full IRIs behind a JSON-LD document, or make expanded data readable with a chosen context. Supply every remote context locally and download the processor result with a visible node and context-load summary.

Steps

  1. Open or paste a JSON-LD object or array and select expand or compact.
  2. Provide exact local context documents and, for compaction, compactContext in the secondary JSON envelope. Set the document base explicitly if relative IRIs need one.
  3. Review node count, mapped contexts and any empty result, then download the resulting JSON-LD.

Available options

Operation
Expand · Compact
Document base IRI (empty for none)
Enter as needed
Protect CSV cells in spreadsheets
On by default

Capabilities and limits

  • One UTF-8 file or pasted JSON-LD document up to 1 MiB; one secondary JSON envelope up to 1 MiB. Each has at most 10,000 JSON values and nesting depth 32. Duplicate keys, nonfinite values and unsafe integers reject rather than silently changing data. The result is limited to 10 MiB, 200,000 JSON values and depth 64. Selected file takes precedence.
  • Processing mode is fixed to JSON-LD 1.1. Secondary input is {"contexts":{"https://example.com/context":{"@context":{...}}},"compactContext":{...}}. Only these two envelope keys are supported. Each mapped document must contain @context; at most 32 exact absolute HTTP(S) URL keys and 64 loader calls. A missing URL always rejects; no fetch, redirects, registry, HTTP headers or scripts.
  • Choose expand or compact. Compact requires a supplied non-null compactContext, which can refer to a locally mapped URL. The document-base field must be empty or an absolute IRI; empty supplies no document base. Inline @base declarations still have their normal JSON-LD meaning. Unbound terms may disappear, and an empty expansion is a valid result.
  • Results preserve JSON-LD processing semantics, not original key ordering or number spelling. Numeric values use finite IEEE-754 doubles; unsupported unsafe integers reject. This task provides no RDF inference, SPARQL, signature validation or reconstruction of the input text. Preview shows the first 200 top-level nodes; the JSON-LD download is complete. The CSV download is a complete top-level node summary with index, IRI and key list, independently limited to10 MiB; exceeding it rejects the entire run without partial files.
Open Offline JSON-LD expander and compactor →
RDF dataset canonical comparisonCompare two local RDF N-Quads datasets using RDFC-1.0 canonicalization, including renamed blank nodes and named graphs.

Find out whether two RDF exports describe the same dataset despite different blank-node labels. Download both canonical datasets and inspect additions and removals from their separately canonicalized line sets.

Steps

  1. Paste strict N-Quads on both sides, or open the left local export and paste the right one.
  2. Run canonical comparison and check equivalence, unique quad counts and additions/removals.
  3. Download left and right canonical N-Quads plus the comparison report. Treat blank-node-heavy differences as a dataset comparison, not a minimal edit plan.

Available options

Protect CSV cells in spreadsheets
On by default

Capabilities and limits

  • One UTF-8 file or pasted left dataset plus a pasted right dataset, combined up to 2 MiB and 10,000 parsed quads. Empty datasets are valid. Repeated identical quads have set semantics and duplicate counts are reported. Selected left file takes precedence.
  • Strict RDF 1.1 N-Quads only: absolute IRIs, blank nodes, datatype/language literals and named graphs. Turtle prefixes, RDF/XML, RDF-star, relative IRIs and invalid quad roles reject. Language tags are normalized to lowercase by the parser; lexical IRI and datatype meanings are retained. No inference or automatic IRI alignment.
  • Canonicalization is explicitly RDFC-1.0 with SHA-256, not an undeclared algorithm alias. Each connected blank-node component is limited to 256 nodes, deep iterations to 10,000, and work to a 10-second deadline. Exceeding a work budget rejects atomically. Cancellation uses the dedicated worker and algorithm abort signal. Canonical downloads are combined up to 10 MiB.
  • Added and removed lines compare separately canonicalized datasets, not minimum edit distance or persistent blank-node identity. A small graph edit may relabel many blank nodes and enlarge the displayed difference. This tool does not certify RDF signatures. Preview shows the first 200 difference rows; JSON and canonical N-Quads downloads are complete.
Open RDF dataset canonical comparison →
GeoJSON CRS reprojectorReproject strict 2D GeoJSON between explicit WGS84 longitude/latitude and Web Mercator, preserving Feature metadata and polygon holes.

Convert a local geometry to the coordinate system required by your next application. Select both CRS values explicitly, check axis order and area limits, and download GeoJSON with original Feature IDs and properties.

Steps

  1. Open strict 2D GeoJSON and select its known source CRS plus the required target CRS.
  2. Verify axis order, projected-area limits and the coordinate preview; retain unsupported bounds or third coordinates separately if needed.
  3. Download reprojected GeoJSON and its CRS/coordinate report. Use the declared target axis order in the receiving application.

Available options

Source CRS
EPSG:4326 — longitude,latitude (degrees) · EPSG:3857 — easting,northing (meters)
Target CRS
EPSG:4326 — longitude,latitude (degrees) · EPSG:3857 — easting,northing (meters)
Protect CSV cells in spreadsheets
On by default

Capabilities and limits

  • One UTF-8 file or pasted GeoJSON up to 2 MiB, at most 50,000 two-dimensional positions and geometry depth 20. Source JSON parsing additionally allows at most 200,000 values and depth 128, including metadata. Result up to 10 MiB. Selected file takes precedence; preview shows the first 200 positions.
  • Supports only EPSG:4326 longitude,latitude in degrees ↔ EPSG:3857 easting,northing in meters. Select different source and target CRS values; no CRS guessing. Longitude must be within ±180 degrees and latitude within ±85.0511287798066 degrees. Web Mercator axes must be within ±20037508.342789244 meters. Endpoint roundoff is normalized only within 1e-10 degrees or 1e-6 meters.
  • Supports seven nonempty 2D geometry types, GeometryCollection, Feature and FeatureCollection. Feature null geometries and empty FeatureCollections are retained. Lines need at least two positions; closed rings need at least four. Three-dimensional/M coordinates, nonfinite or unsafe coordinate integers, geometry foreign members, and bbox/crs members on geometry/Feature/FeatureCollection reject. Remove or retain those bounds separately before conversion; they are never left stale.
  • Feature IDs, properties and other Feature-level metadata retain their original JSON number tokens, including large integers and precise decimals. Coordinate calculations use finite IEEE-754 doubles. Geometry/ring/hole order is retained; no topology/orientation repair, UTM, grid/datum transformations, geocoding or maps. Outputs explicitly state source/target CRS and axis units in a separate report.
Open GeoJSON CRS reprojector →

Tools used in this article

Schema-bound Protobuf message decoder →Inspect binary Protobuf with a supplied standalone proto2/proto3 schema and explicit message type, including 64-bit integers, field presence and unknown wire records.Avro writer/reader schema compatibility →Check both resolution directions between local Avro JSON schemas, including promotion, aliases, defaults and incompatible results.Offline JSON-LD expander and compactor →Expand or compact JSON-LD 1.1 with inline contexts and a supplied local URL-to-context map, without fetching remote documents.RDF dataset canonical comparison →Compare two local RDF N-Quads datasets using RDFC-1.0 canonicalization, including renamed blank nodes and named graphs.GeoJSON CRS reprojector →Reproject strict 2D GeoJSON between explicit WGS84 longitude/latitude and Web Mercator, preserving Feature metadata and polygon holes.