TDMS Viewer
Inspect TDMS group/channel tree and properties in the browser.
Drop a .tdms file here
or
Your file never leaves your browser.
This tool opens an NI TDMS measurement file and shows what is inside without converting anything: the group and channel tree, each channel's data type and sample count, file/group/channel properties, and a preview of the first samples. Parsing streams in 4 MB slices, so the file never uploads and never loads whole.
The three levels, and why it matters
TDMS is a three-level model and nothing deeper: the file itself, the groups inside it, and the channels inside those. Every level carries its own key-value properties, which is the part people are usually looking for. A sample rate written once at group level applies to every channel under it; a unit string written at channel level applies to that channel alone. Reading a value without knowing which level its scaling came from is how a plot ends up off by a factor.
Internally each object is addressed by a path, and the path is where the quoting rule lives:
/'group1' ← a group
/'group1'/'ch1' ← a channel
/'Bob''s rig' ← an apostrophe in a name is doubled
That last line catches people out when they parse TDMS by hand: a name containing an apostrophe is not escaped with a backslash, it is written twice. The viewer resolves the paths for you and shows the names as they were typed.
What the properties tell you
Properties are free-form — a writer can attach anything — but the ones worth hunting for fall into three groups.
Timing. Waveform attributes describe when the samples happened rather than storing a timestamp per sample. A start time, an increment and sometimes an offset are enough to reconstruct the whole time axis, which is why a channel with a million samples can carry three timing properties and no time column.
Scaling and units. A unit string, gain, offset or an explicit scaling entry tells you whether the numbers are already in engineering units or still raw counts. This is the information a plain CSV export throws away, and the most common reason a converted file is quietly wrong.
Provenance. Operator, test name, hardware serial, acquisition settings — whatever the writer recorded. Useless to a parser and often the only way to work out which run a file is.
Property values come back typed: strings, numbers, booleans and timestamps are all read, and the viewer shows the type beside the value so a numeric-looking string is not mistaken for a number.
Reading a file that was cut short
TDMS is appended segment by segment as the writer flushes, which is what makes it survivable: a process killed mid-acquisition leaves a file whose last segment is incomplete but whose earlier segments are perfectly good. The viewer keeps every complete value and drops only the partial tail, so the sample count you see is what is actually recoverable.
If that count is lower than the acquisition should have produced, the file was truncated rather than misread. Compare it against the timing properties — start time plus increment times sample count gives the span that actually survived.
Worked example
file · title="bench run 14" · operator="hk"
group1 · 2 channels · wf_increment=0.001
├ ch1 · f64 · 100 samples · unit_string="V" · gain=1.5
│ first samples: 0, 0.5, 1, 1.5, …
└ ch2 · f64 · 100 samples · (no unit)
ch1 is in volts and pre-scaled; ch2 declares nothing, so its
numbers are whatever the acquisition wrote — check before plotting.
Parameters
| Parameter | Value | Notes |
|---|---|---|
| Input | .tdms (TDMS 2.0) | little-endian, non-interleaved |
| Shown | tree · dtypes · counts · properties · first 10 samples | |
| Streaming | 4 MB File.slice chunks | no upload, no full load |
| Refused | big-endian · interleaved · DAQmx | named, not guessed at |
| Export | → TDMS to CSV tool | linked below the tree |
Python equivalent
# The same inspection with NI's Python package (pip install nptdms)
from nptdms import TdmsFile
tdms = TdmsFile.read("run.tdms")
print(dict(tdms.properties))
for group in tdms.groups():
for ch in group.channels():
print(group.name, ch.name, len(ch), dict(ch.properties))FAQ
▸What does this viewer show that the converter doesn't?
The structure. Before committing to a CSV export you often just need to know what is inside: which groups and channels exist, their data types, sample counts, and the properties (units, scaling hints, timestamps) attached at file, group and channel level. This page answers that in one drop.
▸Where do TDMS properties come from?
LabVIEW and other NI writers attach key-value properties at every level of the hierarchy — file title, group description, channel unit strings, waveform timing attributes like wf_increment. The viewer lists them verbatim next to the object they belong to.
▸Why does my channel show fewer samples than the acquisition ran?
TDMS appends data in segments as the writer flushes; an application killed mid-write leaves a truncated final segment. The parser keeps every complete value and drops only the partial tail, so the count reflects what is actually recoverable from the file.
▸Which files are supported?
Standard TDMS 2.0: little-endian segments, non-interleaved raw data, numeric channel types (i8–i64, u8–u64, f32, f64). Big-endian, interleaved and DAQmx-scaler files are rejected with a clear message rather than shown incorrectly.
▸Is my file uploaded?
No. It is read in 4 MB slices with the browser's File API and parsed locally.