Private browser utility / Developer

Fixed Width File Parser

Runs entirely in your browser - no upload, no sign-up.

Live workspaceLocal processing

Paste records or open a .txt, .dat, or .fwf file.

One field per line: name,start,length,type

Types: text, integer, number, decimal:n, date:YYYYMMDD, date:YYYY-MM-DD. Use * as the final length to capture the rest of a row.

Parsing options
Your parsed records will appear here

Add source data and a field specification, then parse the records.

Share this tool
fixed width parser / browser utility
01 / Overview

What is a fixed width file parser?

A fixed width file parser splits each record by exact character positions instead of separators. Define each field's name, start, length, and optional type, then inspect row-length and value errors before exporting clean CSV or JSON. Processing stays in your browser, so legacy data is not uploaded.

02

How to use

  1. 01
    Add the records

    Paste fixed-width text or open a local .txt, .dat, or .fwf file.

  2. 02
    Define the fields

    Enter one name,start,length,type row per field, or detect likely columns and verify the suggested 1-based positions.

  3. 03
    Parse and inspect

    Review the table plus warnings for short rows, extra trailing data, and values that do not match their declared type.

  4. 04
    Export the result

    Choose CSV or JSON, then copy the full result or download it locally.

03

Who it's for

  • Data engineers checking a positional feed against a vendor layout before loading it into a pipeline.
  • Finance and operations teams converting bank, ERP, payroll, or claims exports into spreadsheet-ready CSV.
  • Mainframe developers inspecting fixed-length extracts while preserving leading zeroes in account and record IDs.
  • Analysts turning aligned report output into named JSON objects without uploading sensitive records.

Use explicit positions for repeatable imports, or detect likely boundaries from whitespace that stays empty across the sample. The parser preserves identifiers as text, supports implied-decimal amounts and two common date layouts, and keeps invalid source values visible instead of silently dropping a row.

FAQ

Is my fixed-width file uploaded?

No. The file is read and parsed locally by your browser. CanDoYa does not send the source records, field specification, preview, or exported data to a server. This makes the parser suitable for sensitive samples, although you should still follow your organization's data-handling rules.

Is the fixed width file parser free?

Yes. You can define fields, detect likely columns, validate records, preview the result, and export CSV or JSON without an account or payment. The browser workspace accepts up to 2 MB and 50,000 records so it stays responsive on typical inspection and conversion jobs.

What limits does the parser have?

One run can process up to 2 MB, 50,000 records, and 100 fields. Positions are Unicode character offsets rather than raw byte offsets. The parser handles text that is already decoded in the browser, not binary EBCDIC files or copybooks that require record-type logic.

How do I write a fixed-width field specification?

Write one field per line as name,start,length,type. Starts are 1-based. For example, account_id,1,8,text reads eight characters from position 1. The type is optional and can be text, integer, number, decimal:n, date:YYYYMMDD, or date:YYYY-MM-DD.

What does decimal:2 mean?

decimal:2 treats the final two digits as an implied fractional part. A source value of 0000014500 becomes 145.00. This is common in financial flat files that omit the decimal point. Invalid digits remain visible and receive a validation warning.

Can the parser detect columns automatically?

Yes. Detect columns looks for character positions that are blank across up to 200 nonblank sample rows. It is a useful starting point for aligned reports, but explicit positions from the file layout are safer when values can fill the padding or fields sit directly beside one another.

Why is a row marked short or long?

A short row ends before the last fixed-length field does. A long row has non-space characters beyond the final specified position. Both can signal a changed layout, a truncated record, or an incorrect field length, so the parser reports the source line instead of hiding the mismatch.