Pipe to JSON array converter

Four operations, applied in a fixed order, with no configuration exposed. The input is split on the pipe character. Each resulting piece is trimmed of leading and trailing whitespace. Any piece that is now the empty string is discarded. What survives is serialised as a JSON array with a two-space indent.

That order matters more than it looks. Trimming happens before the emptiness test, so a field of three spaces and a field of zero characters are indistinguishable by the time the test runs, and both are removed.

The whole computation happens in the page. There is no request, therefore no server-side allowance to spend and no imposed length ceiling.

Exactly one step is lossy in a way you cannot recover from the output: discarding empty pieces. Splitting and trimming are predictable, and serialisation is faithful. Dropping empties destroys the correspondence between a field's position in the input and an item's index in the output.

Concretely, a record whose second field is blank yields an array in which the third input field is the second item, and nothing in the output marks where the gap was. Two records from the same log that differ only in whether an optional field was populated produce arrays of different lengths, and the JSON alone cannot tell you which is which.

Positional access is therefore safe only for formats with no optional fields. Where optional fields exist, assert on the array length before reading anything by index.

No preliminary configuration exists to get wrong. This route publishes no options, so the delimiter is fixed and the four transformation steps are not adjustable.

Step 1

Paste the pipe-delimited input. The character and word meter above the field confirms the paste arrived whole.

Step 2

Run the conversion. Split, trim, discard and serialise all execute on your device.

Step 3

Copy the result, then assert on its length before reading any item by index.

No type inference is attempted. A piece that looks numeric is written as a JSON string, and so is anything resembling a boolean or a null.

Type inference on delimited text is where identifiers quietly break: a zero-padded reference loses its padding, a long numeric identifier loses precision at the far end, and a code that reads as a number stops comparing equal to the string it came from. Declining to infer keeps the output a faithful record of the characters between the pipes.

The cost is that anything genuinely numeric needs casting downstream. That cost is visible and easy to apply. The cost of silent inference is invisible and surfaces much later.

A delimiter choice is a bet on rarity. Whoever designed a pipe-delimited format bet that no field value would contain a pipe, which is far safer than the same bet on commas or spaces, since those appear inside names, addresses and free text constantly. That is why the format survives in audit trails and legacy flat-file exports.

The bet fails in two ways, and this converter detects neither. A value that genuinely contains a pipe is split, leaving the output one item longer than the record has fields, with no error raised. A quoted field containing a pipe is also split, because the quotes are not interpreted, and the quote characters end up distributed across two items.

Neither case produces an obvious failure. Both produce well-formed JSON that is simply wrong, which is why checking the item count is worth the two seconds it takes.

A Markdown row is bounded by pipes as well as separated by them, so a plain split produces an empty piece before the first cell and another after the last. Because empties are discarded, the output is the cell values and nothing else. That is two rules lining up, not Markdown support.

The escape is where it stops helping. A cell containing a literal pipe is written with a backslash before it, a convention the converter knows nothing about, so the row splits there and the backslash is stranded at the end of the preceding item. An item terminating in a backslash is the reliable signature of this case.

Nor is there a concept of a table. The alignment row splits like any other line, into items of dashes and colons, and a multi-row table is one undifferentiated block of text.

It does not emit an array of objects. There is no header row detection, no key assignment and no object mode, so field names are the reader's responsibility. It does not interpret quoting, escaping or Markdown syntax, and it does not infer types. It does not treat a line break as a delimiter, so a multi-line paste yields one array in which items spanning row boundaries still contain their line breaks.

It exposes no options at all, which means trimming, discarding empties and indenting to two spaces are fixed rather than chosen. There is no minified output, no file input, no download, no batch mode and no API. Each of these is something a reader might otherwise assume, and an assumption that survives until the output is already in a pipeline is expensive.

The dominant case is a single log line under examination. An engineer reading a pipe-delimited audit record wants the fields separated and countable, once, for a question they are answering now. Writing a parser for that is disproportionate.

The second is a one-off record from a legacy export, where accounting, inventory and mainframe-adjacent systems still produce pipe-delimited flat files. The third is documentation work, lifting a Markdown table row into a configuration object. All three share the property that makes this worth having: the job is small, immediate, and not worth automating.