JSON to Sequelize Model Generator

Example Input

{
  "id": 1,
  "name": "Priya Singh",
  "email": "priya@learnhubly.com",
  "isActive": true,
  "score": 98.5,
  "tags": ["developer", "admin"],
  "profile": {
    "bio": "Principal Software Engineer"
  },
  "deletedAt": null
}

Example Output

const { DataTypes } = require('sequelize');
const sequelize = require('../config/database');

const User = sequelize.define('User', {
  id: {
    type: DataTypes.INTEGER,
    primaryKey: true,
    autoIncrement: true,
  },
  name: {
    type: DataTypes.STRING,
  },
  email: {
    type: DataTypes.STRING,
  },
  isActive: {
    type: DataTypes.BOOLEAN,
  },
  score: {
    type: DataTypes.FLOAT,
  },
  tags: {
    type: DataTypes.JSON,
  },
  profile: {
    type: DataTypes.JSON,
  },
  deletedAt: {
    type: DataTypes.STRING,
    allowNull: true,
  },
});

module.exports = User;

Does it handle associations?

The tool generates single model definitions — associations like hasMany, belongsTo, hasOne, and belongsToMany are not generated because they depend on the relationships between multiple models, not just the structure of a single JSON object. After generating the individual models for your entities, define associations in your model files or in a separate associations setup file: User.hasMany(Post, { foreignKey: 'authorId' }) and Post.belongsTo(User, { foreignKey: 'authorId' }). The generated models are the starting point — associations are the next step you define based on your domain model.

Does it support MySQL, PostgreSQL, SQLite, and MSSQL?

Yes. The generated Sequelize model code uses standard Sequelize DataTypes (DataTypes.STRING, DataTypes.INTEGER, DataTypes.BOOLEAN, etc.) that Sequelize maps to the appropriate underlying SQL types for each database dialect. The same model definition works across MySQL, MariaDB, PostgreSQL, SQLite, and MSSQL without modification. The only difference is in the actual database column types Sequelize creates — DataTypes.BOOLEAN creates TINYINT(1) in MySQL and BOOLEAN in PostgreSQL. Your application code works identically regardless of the database.

Is it safe for sensitive data?

Yes. All JSON parsing and Sequelize model code generation runs entirely in your browser using JavaScript. Your JSON payload data — including field names, internal data model structures, and sample values that may indicate your application's domain — never leaves your machine and is never transmitted to any server. This is relevant for teams where internal data model structure is considered proprietary or where API response schemas contain information about business logic.

How do I use the generated model with Sequelize associations?

After generating and saving your model files, define associations in each model file or in a central index.js that imports all models. For a User that has many Posts: in User.js or after the model definition, add User.associate = (models) => { User.hasMany(models.Post, { foreignKey: 'authorId', as: 'posts' }) }. In Post.js: Post.associate = (models) => { Post.belongsTo(models.User, { foreignKey: 'authorId', as: 'author' }) }. Then in your database initialization, call model.associate(models) for each model. This pattern is the standard Sequelize project structure.

What is the difference between DataTypes.STRING and DataTypes.TEXT?

DataTypes.STRING maps to VARCHAR(255) in MySQL — it can store up to 255 characters. DataTypes.STRING(500) maps to VARCHAR(500). DataTypes.TEXT maps to TEXT in MySQL and TEXT in PostgreSQL — it stores unlimited length text. Use DataTypes.STRING for short, fixed-length values like names, email addresses, status codes, and URLs (though long URLs may exceed 255 characters). Use DataTypes.TEXT for variable-length content that might be longer — article bodies, product descriptions, user bios, comment text, log messages. The generated model uses DataTypes.STRING for all JSON string fields — review and change to TEXT for any field that will store long content.

How do I add timestamps (createdAt, updatedAt) to my Sequelize model?

Sequelize adds createdAt and updatedAt columns automatically to every model by default — you do not need to declare them in the field definitions. When you use Model.create() Sequelize sets createdAt and updatedAt automatically. When you use Model.update() Sequelize updates updatedAt automatically. If the generated model includes createdAt or updatedAt as field definitions (because they appeared in your JSON sample), remove them and let Sequelize manage them. To disable automatic timestamps entirely, add timestamps: false to the model options: sequelize.define('User', { fields }, { timestamps: false }).

Does it work with Sequelize TypeScript (sequelize-typescript)?

The generated code uses the CommonJS require() syntax and the sequelize.define() API which is the standard JavaScript Sequelize approach. The sequelize-typescript package uses a different syntax — class-based models with TypeScript decorators: @Table, @Column, @Model. If your project uses sequelize-typescript, the generated code is a useful reference for field names and types, but you will need to convert the structure. Each field declaration like name: { type: DataTypes.STRING } becomes a class property with the @Column decorator: @Column(DataTypes.STRING) name: string. The DataTypes themselves are the same — only the structural syntax changes.

How do I run database migrations with the generated model?

The generated model defines the JavaScript interface to the database but does not create the database table. To create the table in the database, you have two approaches. First, for development: use sequelize.sync() which creates tables that do not exist based on your model definitions — sequelize.sync({ force: true }) drops and recreates. Second, for production: use Sequelize CLI migrations. Install sequelize-cli and run npx sequelize-cli migration:generate --name create-users to generate a migration template, then copy the field definitions from the generated model into the migration's up() function using queryInterface.createTable(). Migrations are the correct production approach because they give you version-controlled, reversible database changes.