skip to content

In JMeter, what decides whether a results file is written as CSV or as XML?

level: middleimportance: should knowfreq 44%

answer

  1. One property, two supported values
  2. The default is the compact one
  3. Case-sensitive match against a literal
  4. The file extension decides nothing
  5. A listener carries its own saved copy

basics

~10 s

The jmeter.save.saveservice.output_format property decides it, and it defaults to csv. Only the exact lowercase value xml selects XML; anything else logs a warning and falls back to CSV. The file name is irrelevant.

solid answer

~40 s

`jmeter.save.saveservice.output_format` selects the format for files JMeter writes, and its default is `csv`. The comparison is a case-sensitive match against the literal `xml`, so `XML`, `Xml` or the `db` value the shipped comment still lists all miss, and JMeter logs *has unexpected value ... assuming 'csv' format* and writes CSV anyway. Nothing keys off the file extension: `results.xml` will happily contain CSV. A listener in the plan carries its own copy of the save configuration inside the `.jmx`, set through its Configure button, and that copy wins for that listener; the top-level collector created by `-l` uses the property defaults. XML is what you need if you want response bodies, headers or sampler data, because those items have no CSV column at all.

code

properties · 4 lines
properties
# user.properties on the injector
jmeter.save.saveservice.output_format=xml
jmeter.save.saveservice.response_data=true
jmeter.save.saveservice.subresults=true

go deeper

for a junior

Know that JMeter can write results as CSV or XML, that CSV is the default, and that one property in jmeter.properties chooses between them.

for a middle

Name jmeter.save.saveservice.output_format, state its default, and explain that the match is exact and that anything unrecognised silently falls back to CSV with a log warning.

for a senior

Diagnose the mismatch in the wild: a listener's saveConfig stored in the .jmx overriding the property file, an XML file left unparseable by a killed run, response_data set on a CSV file and doing nothing.

for a principal

Decide once, for everyone, which format a keepable run writes and where that setting lives, so files gathered from different injectors and different plans can be read by one tool without per-file archaeology.

Two formats, one property, and a surprising number of ways to end up with the one you did not want. This matters most for a file you intend to keep: the format is baked in at write time, and nothing in the file name records the decision. ## The property and its exact match `jmeter.save.saveservice.output_format` takes `csv` (the default) or `xml`. The shipped comment reads *legitimate values: xml, csv, db. Only xml and csv are currently supported*, so `db` is documented but dead. The check in the code is a plain case-sensitive comparison against `xml`; every other value, including `XML`, takes the fallback branch, which logs a warning naming the property and the bad value and then writes CSV. The warning goes to `jmeter.log`, not to the console banner, which is exactly why it gets missed. ## What each format can hold | | CSV | XML | |---|---|---| | One sample is | one line | one `<httpSample>` or `<sample>` element | | Column/attribute names | header line, if `print_field_names` | short attributes such as `t`, `lt`, `ct`, `ts`, `by` | | Sub-samples | extra flat rows | nested child elements | | Response data, headers, sampler data | not available | available as child elements | | File wrapper | none | XML declaration plus `<testResults version="1.2">` | | Size | small | considerably larger | The shipped property file is blunt about the asymmetry: *response_data is not currently supported for CSV output*. So setting `jmeter.save.saveservice.response_data=true` while `output_format` is `csv` changes nothing at all — there is no column for it to land in. ## Where the setting is actually read from There are two paths and they behave differently: - **The `-l` collector.** JMeter builds a top-level result collector for the run and gives it the configuration derived from the property files, so `output_format` in `jmeter.properties` or `user.properties` governs it. - **A listener in the plan.** Every listener owns a save configuration that is serialised into the `.jmx` under `saveConfig`, edited through the listener's Configure button. That stored copy is what the listener writes with, so a plan checked in years ago can carry a format choice nobody remembers making. Two things are deliberately *not* stored in the `.jmx` and always come from the properties: the field delimiter and whether the timestamp is printed as milliseconds. Keep that in mind when a file will be read on a different machine. ## Choosing one for a file you will keep - **CSV** for anything that will be summarised, gated, or loaded into a tool. It is compact, it is the format the report tooling expects, and one line per sample survives being cut in half by a truncated upload. - **XML** when the point of the run is the responses themselves — debugging a small functional pass where you want the bodies and headers alongside the timings. A practical hazard for a kept file: an XML JTL is only well-formed once its closing `</testResults>` has been written. A run killed mid-flight leaves an XML file that no parser will open, whereas a CSV file truncated at the same instant loses at most the final line. If the file is evidence, that asymmetry usually settles the argument on its own.

  • You set jmeter.save.saveservice.output_format=XML and the file is still comma separated. Why?
    The value is compared case-sensitively against the literal `xml`, so `XML` misses. JMeter logs that the property has an unexpected value and assumes `csv`, then writes CSV. The warning is in `jmeter.log`; nothing on the console says the format was ignored.
  • Does setting jmeter.save.saveservice.response_data=true put response bodies into a CSV JTL?
    No. The shipped property file states that response data is not supported for CSV output, and the CSV writer has no field for it. The flag only takes effect when the file is written as XML.
  • Why is a killed run's XML JTL often unusable when the CSV one is fine?
    The XML file only becomes well-formed when JMeter writes the closing `</testResults>` tag at the end of the run. Kill the process first and no parser will open it. A CSV file has no wrapper, so a hard stop costs you at most the last partial line.

saying these in an interview costs you the question

  • Thinks the file extension selects the format
  • Says output_format accepts XML in any casing
  • Believes response bodies can be saved into CSV columns
  • Assumes a listener in the plan follows the properties file
  • Claims db is a working output_format value