Every integration project eventually meets the same problem. One system calls a field "first", another calls it "givenName". One stores a full name in a single field, another stores given and family names separately. One nests an address inside an object, another flattens it into prefixed fields. The data is the same; the shape is different. Translating between shapes by hand is tedious and error-prone, and writing a one-off script for a small job is often more work than the translation itself. The Data Mapping Transformer takes a JSON array of records and a set of mapping rules, and returns reshaped records, in your browser, without code.
Mapping is best understood as a set of small, named operations rather than one mysterious transformation. Renaming changes a field's name while keeping its value. Joining combines two or more fields into one, such as building a full name from given and family names. Other operations reshape structure: moving a field, dropping a field that the destination does not need, or combining fields with a separator. Each rule is small and checkable, and a mapping made of small rules can be read, reviewed and corrected rule by rule. A mapping expressed as one large opaque script cannot.
How the tool works
You paste a JSON array of records and define mapping rules, and the tool applies those rules to each record and returns the transformed array. Everything runs in your browser, so the data never leaves your device. The per-record application matters: the same rules run over every record in the array, so a mapping that works for the first record works for the thousandth, provided the records share the same shape. That uniformity assumption is worth checking, because real data often mixes shapes. A record missing a field that a rule expects needs a defined behaviour, whether that means leaving the output field blank, skipping it, or flagging the record, and you should know which behaviour you are getting before you run a large array through it.
Rules should be written in the order they will be read. Rename rules first, so the rest of the mapping refers to the new names consistently, then join rules that combine renamed fields, then any rules that drop fields no longer needed. That ordering is a convention, not a requirement of the tool, but conventions are what make a mapping readable to the next person. A mapping that another person can read is a mapping that can be maintained; a mapping that only its author understands will be rewritten from scratch the next time it needs changing.
A worked example
Take a single record: {"first": "Ana", "last": "Ray"}. Apply rename rules that map first to givenName and last to familyName. The result is {"givenName": "Ana", "familyName": "Ray"}. Nothing else changed. The values are identical, the order of the fields follows the rules, and the record now matches the destination system's naming. That is the simplest useful mapping, and it is also the most common: two systems, same data, different names.
Now add a join rule that combines givenName and familyName with a space into fullName. Applied to the same record, the join produces "Ana Ray". Join rules need a separator specified explicitly, because the difference between "Ana Ray", "AnaRay" and "Ray, Ana" is entirely the separator and the order, and a tool that guessed either would guess wrong half the time. A join also needs a decision about missing parts: if a record has a given name but no family name, the joined value should not contain a trailing space or a stray separator. Check the tool's behaviour on a record with a missing part before running a full dataset, and clean the data if the behaviour does not match your need.
Common mistakes
The most common mistake is mapping field names without checking that the values mean the same thing. Two systems can both have a field called "name" where one holds a person's full name and the other holds a username, and a rename that equates them corrupts the data while looking correct. Always compare sample values, not just field names. A second mistake is assuming every record has every field. Real arrays mix complete and partial records, and a rule that expects a field that is absent will produce blanks, errors or surprises depending on handling. Test the mapping on records that are missing fields, not only on perfect ones.
A third mistake is joining fields in the wrong order or with the wrong separator, which produces values that look plausible but sort and match incorrectly. "Ray Ana" is not the same as "Ana Ray" for display, sorting or searching. A fourth mistake is dropping fields too early. A field the destination does not need today may be the field you need for debugging tomorrow, when a transformed record looks wrong and you want to compare it against the original. Keep the original array, and consider keeping a copy of unmapped fields until the mapping has been verified end to end.
Honest limitations
A mapping transformer reshapes records according to rules; it does not understand your data. It cannot tell that two fields with the same name mean different things, cannot validate values, cannot repair inconsistent records, and cannot fetch missing data from another source. It works on the pasted JSON array, so very large arrays may be awkward, and it assumes records share a broadly consistent shape. It also cannot guarantee that the destination system will accept the transformed records; field types, required fields and value formats on the destination side still need checking against that system's own documentation. The transformer makes the translation mechanical and repeatable, but the judgement about what the translation should be remains human work.
Closing
Data mapping is translation, and good translation is done in small, named, checkable rules. Rename first, join with an explicit separator, test on imperfect records, and keep the original. A record that enters as {"first": "Ana", "last": "Ray"} and leaves as a correctly named, correctly joined record is the whole job done right. For neighbouring jobs, JSON Studio helps you inspect records before and after mapping and the JSON to CSV Converter changes format once the shape is right, while How to Format and Validate JSON keeps the JSON itself valid throughout.