mongoimport accepts JSON in two forms: a single document per line (JSONL) or a JSON array passed with --jsonArray. The array form is more convenient for files you have generated from another source because you can inspect the array as a whole, validate the syntax with standard JSON tools, and load it in a single command. FixTools produces the array form by default, so the conversion output drops straight into mongoimport --jsonArray --collection mycoll --file converted.json with no intermediate transformation.
Typing matters in MongoDB because BSON has distinct types for integers, doubles, and strings. Storing a price field as "12.99" rather than 12.99 means range queries do not work as expected and aggregation pipelines have to coerce on every operation. Type inference at conversion time emits real numbers for numeric columns, which BSON encodes as either Int32 or Double depending on whether decimal points appear. Boolean fields become real booleans which support direct boolean queries.
Sub-documents are the natural MongoDB way to represent nested structure, and dot-notation in your CSV headers maps directly to BSON sub-documents through the standard MongoDB dot-notation convention. A header address.city becomes documents like { address: { city: ... } } in the array, which then loads as BSON sub-documents. The same notation works for arrays inside documents using bracket-index syntax, producing tags arrays and arrays of line items where appropriate.
ObjectId, ISODate, and other extended BSON types are not auto-generated by the converter because they require either MongoDB Extended JSON syntax or post-load processing. If your data should have an _id field of ObjectId type, leave it out of the CSV and let MongoDB generate ObjectIds on insert. For dates, store ISO 8601 strings in the CSV and let an aggregation pipeline convert them to BSON dates after load with $toDate. This keeps the converter focused on portable JSON rather than locking the output to MongoDB-specific syntax.