Automatic type declaration for JSON input data https://github.com/mgajda/json-autotype

Version on this page:1.0
LTS Haskell 7.19:1.0.15
Stackage Nightly 2016-09-14:1.0.14
Latest on Hackage:1.0.15
BSD3 licensed by Michal J. Gajda
Maintained by mjgajda@gmail.com

Module documentation for 1.0

There are no documented modules for this package.


Takes a JSON format input, and generates automatic Haskell type declarations.

Parser and printer instances are derived using Aeson.

The program uses union type unification to trim output declarations. The types of same attribute tag and similar attribute set, are automatically unified using recognition by attribute set matching. (This option can be optionally turned off, or a set of unified types may be given explicitly.) :|: alternatives (similar to Either) are used to assure that all JSON inputs seen in example input file are handled correctly.

I should probably write a short paper to explain the methodology.

Build Status Hackage Hackage Dependencies

Details on official releases are on Hackage


After installing with cabal install json-autotype, you might generate stub code for the parser:

    json-autotype input1.json ... inputN.json -o MyFormat.hs

Then you might test the parser by running it on an input file:

    runghc MyFormat.hs input.json

At this point you may see data structure generated automatically for you. The more input files you give to the inference engine json-autotype, the more precise type description will be.

Algorithm will also suggest which types look similar, based on a set of attribute names, and unify them unless specifically instructed otherwise.

The goal of this program is to make it easy for users of big JSON APIs to generate entries from example data.

Occasionally you might find a valid JSON for which json-autotype doesn't generate a correct parser. You may either edit the resulting file and send it to the author as a test case for future release.

Patches and suggestions are welcome.


The most simple example:


It will produce the module with the following datatypes and TH calls for JSON parser derivations:

    data ColorsArray = ColorsArray {
        colorsArrayHexValue    :: Text,
        colorsArrayColorName :: Text
      } deriving (Show,Eq)

    data TopLevel = TopLevel {
        topLevelColorsArray :: ColorsArray
      } deriving (Show,Eq)

Note that attribute names match the names of JSON dictionary keys.

Another example with ambiguous types:

                "parameterValue":"site API"

It will produce quite intuitive result (plus extra parentheses, and class derivations):

    data Parameter = Parameter {
        parameterParameterValue :: Bool :|: Int :|: Text,
        parameterParameterName :: Text

    data TopLevel = TopLevel {
        topLevelParameter :: Parameter

Real-world use case examples are provided in the package source repository.

Other approaches:

There is a json-sampler that allows to make simpler data structure from JSON examples, but doesn't seem to perform unification, nor is it suitable for big APIs.



1.0.15  Dec 2016
    * Support YAML input.

1.0.14  May 2016
    * Update to latest lens.

1.0.13  Mar 2016
    * Bumped up hint upper bound for v0.5.

1.0.12  Mar 2016

    * Fixed issue #8 - misrepresenting Double as Int.
    * Fixed issue #9 - efficient formatting with new Aeson-0.10 builder (toEncoding.)

1.0.11  Mar 2016

    * Updated to GHC 8.0

1.0.10  Sep 2015

    * Fixed bug appeared with aeson 0.10 breaking change:

1.0.8  Sep 2015

    * Dependency bump for lens 4.13 and aeson 0.10.

1.0.7  Jul 2015

    * Dependency bump for lens and vector.

1.0.6  Jun 2015

    * Make lens and aeson versions consistent in the *.cabal file.

1.0.3-1.0.5  Jun 2015

    * Bumped Aeson dependency up.
    * Tiny docs corrections.

1.0.2  Jun 2015

    * Relaxed dependency for lens-4.11.

1.0.1  Apr 2015

    * Relaxed dependency to lens-4.10.

1.0  Apr 2015

    * First stable release.

0.5  Apr 2015

    * Reduced name space pollution when generating code.
      Now all valid JSON test examples do work.
    * Corrected build failure on GHC 7.8.4

0.4  Apr 2015

    * Release candidate for current functionality.

0.3  Apr 2015

    * Passed all smallcheck/quickcheck tests.
    * Approaching release candidate.  Apr 2015

    * Correctly handling lone option, not yet union with optionality.
      Fixed: #3.  Apr 2015

    * Added typechecking before and after type unification.
    * Added shrink for more informative QuickCheck testing.
    * Tested mostly using GHC 7.10.  Mar 2015

    * Add short versions of command line flags: -o, -d, and -t.  Mar 2015

    * Bump up lens dependency.  Mar 2015

    * Updated tests and build config.  Mar 2015

    * Fixed documentation anchors, and unit test classification for failures.  Mar 2015

    * Relaxed upper bounds for lens 4.8.  Mar 2015

    * (Skipped this version number by mistake.)  Dec 2014

    * Relaxed upper bounds for new lens.  Dec 2014

    * Relaxed upper bounds again.  Dec 2014

    * Updated metainfo, relaxed upper bounds for GHC 7.10.  Nov 2014

    * Nicer union type syntax in Data.Aeson.AutoType.Alternative.  Nov 2014

    * To assure proper treatment of unions,
      I make them with Data.Aeson.AutoType.Alternative type instead of Either.  Nov 2014

    * Explicit JSON parser generation to avoid conflicts between Haskell keywords and field names.
    * Renaming of Haskell field names with a prefix of object name (data type.)  Nov 2014

    * GenerateJSONParser may now take multiple input samples to produce single parser.
    * Fixed automated testing for all example files.  Oct 2014

    * Added examples to the package distribution.  Oct 2014

    * Cleaned up package.
    * Changelog in markdown format.

0.2.1  Oct 2014

    * Added option to use it as a filter ('-' is accepted input name.)

0.2.0  Oct 2014

    * First release to Hackage.
    * Handling of proper unions, and most examples.
    * Automatically tested on a wide range of example documents (see
    * Initial documentation in README.md.

0.1.0  July 2014

* First experiments uploaded to GitHub, and discussed to
comments powered byDisqus