Conversion status
Every non-empty line becomes one JSON object with a line number and text field.
Paste arbitrary lines, choose an encoding label, normalize each line to UTF-8 JSONL, and download the result. The browser handles the conversion; process priority and core scheduling stay outside this artifact.
Every non-empty line becomes one JSON object with a line number and text field.
The original app is C# and multithreaded. This browser version keeps the useful data transformation explicit and honest.
UTF-8 normalized output ready to download.
No output yet.
Five entered lines with two blank or whitespace only lines produce three JSON objects. The retained text preserves its original surrounding spaces. Record numbers are one, two and three after filtering; they are not the original physical line numbers one, three and five. Bars use one hundred pixels per line to compare five source lines with three retained records. This runs in the browser and does not use a model, a C sharp application or operating system thread scheduling. The bar width is record count divided by twenty times one hundred percent, capped at one hundred. Five records show twenty five percent, twenty records one hundred percent, and twenty five records still one hundred percent. Bars share four hundred pixels for the full capped width. This is a count display, not elapsed conversion progress, throughput or CPU utilization. Reload restores saved text and preview but does not recompute the count until a real conversion input or action. There are four selectable encoding labels, but all four run the same JavaScript string splitting and JSON serialization. No byte decoder reads an uploaded file. One nonempty entered line yields one object under every label. Four equal bars use two hundred pixels per output object. JSON serialization escapes quotes and control characters while retaining Unicode text. The downloaded Blob is a browser string with an application jsonl media type, not proof that any original file bytes used the selected encoding.