NFT Metadata Guide 2026: JSON Structure, IPFS, OpenSea Standards & Free Generator

Everything you need to structure NFT metadata correctly in 2026 — covering ERC-721, ERC-1155, Solana Metaplex, and ERC-6551 standards. Learn JSON formatting, IPFS and Arweave storage strategies, marketplace-specific requirements for OpenSea, Blur, and Magic Eden, plus generate your metadata free with our no-code tool.

Updated: March 1, 2026 25 min read Crypto Tools
NFT Metadata Guide 2026 - JSON Structure, IPFS Storage, and OpenSea Standards

Understanding NFT Metadata Fundamentals

NFT metadata is the backbone of every digital collectible, defining how your tokens appear, function, and rank across blockchain marketplaces. In 2026 — with renewed crypto market activity following the 2024 ETF approvals — proper metadata structure is more critical than ever. Whether you're building a PFP collection, creating in-game item NFTs, tokenizing real-world assets, or launching an NFT-based loyalty program, getting your metadata right determines whether your project succeeds or breaks on every major marketplace.

2026 Market Reality: NFT use cases have expanded far beyond art and PFP collections. Web3 game developers, RWA tokenizers, music rights holders, and loyalty program builders all rely on properly structured metadata — each with different requirements across Ethereum, Solana, and L2 chains like Base and Arbitrum.

This guide covers every standard you need in 2026: ERC-721, ERC-1155, Solana Metaplex, and ERC-6551 Token-Bound Accounts. You'll learn the correct JSON structure, how to choose between IPFS, Arweave, and on-chain storage, and what each major marketplace requires. When you're ready to create your metadata, our free NFT Metadata Generator handles the formatting automatically.

NFT Metadata Standards and Schema Structure

Understanding metadata standards ensures marketplace compatibility and optimal user experience:

OpenSea Metadata Standard (ERC-721/1155)

{
  "name": "Awesome NFT #1",
  "description": "This is an awesome NFT from our collection",
  "image": "ipfs://QmY4XzNrQz3nJ5xF8kP6qH9xG3dK7hG2jD1nM4xK5cF8",
  "external_url": "https://myproject.com/token/1",
  "attributes": [
    {
      "trait_type": "Background",
      "value": "Blue"
    },
    {
      "trait_type": "Rarity",
      "value": "Legendary",
      "max_value": 100
    },
    {
      "display_type": "boost_percentage",
      "trait_type": "Power Boost",
      "value": 15
    }
  ],
  "background_color": "000000",
  "animation_url": "ipfs://QmAnimationHash...",
  "youtube_url": "https://youtube.com/watch?v=..."
}

Essential Metadata Fields

Field Required Description Example
name Yes NFT display name "CryptoPunk #7804"
description Yes NFT description "Rare punk with alien type"
image Yes Image URL or IPFS hash "ipfs://QmHash..."
attributes Recommended Trait array for filtering [{"trait_type": "Eyes", "value": "Blue"}]
external_url Optional Project website link "https://myproject.com/1"
animation_url Optional Video/GIF/3D model URL "ipfs://QmVideoHash..."

Advanced Trait Systems and Rarity Design

Creating compelling trait hierarchies that drive collector interest and secondary market value:

Trait Type Categories

Visual Traits
  • Background: Scene/color variants
  • Body/Base: Main character form
  • Accessories: Hats, jewelry, items
  • Expressions: Eyes, mouth variations
  • Clothing: Outfits and styles
Utility Traits
  • Rarity Level: Common to Legendary
  • Power/Stats: Numeric values
  • Generation: Release batch
  • Special Events: Limited editions
  • Utility Access: Membership levels

Rarity Distribution Strategy

Recommended Rarity Percentages (10K Collection):

  • Common (60%): 6,000 NFTs - Basic traits
  • Uncommon (25%): 2,500 NFTs - Enhanced features
  • Rare (10%): 1,000 NFTs - Special attributes
  • Epic (4%): 400 NFTs - Premium traits
  • Legendary (0.9%): 90 NFTs - Ultra rare
  • Mythic (0.1%): 10 NFTs - One-of-a-kind

Trait Combination Rules

Concept: Certain traits cannot appear together
Example: "Helmet" and "Hat" cannot coexist
Implementation: Logic checks during generation prevent conflicts

Concept: Some traits require others to be present
Example: "Earrings" require "Pierced Ears"
Implementation: Conditional trait assignment based on prerequisites

Concept: Specific trait combinations create ultra-rare variants
Example: "Golden Skin" + "Diamond Eyes" = "Celestial Being"
Implementation: Bonus rarity multipliers for perfect combinations

IPFS Integration and Storage Solutions

Decentralized storage is crucial for long-term NFT sustainability and true ownership:

IPFS vs Traditional Storage

Aspect IPFS Centralized Storage Recommendation
Decentralization Fully decentralized Single point of failure IPFS for permanence
Speed Moderate (depends on pins) Fast (CDN optimized) Hybrid approach
Cost Low (after initial pinning) Ongoing hosting fees IPFS for cost efficiency
Immutability Content-addressed Can be changed/deleted IPFS for integrity

IPFS Implementation Workflow

Professional IPFS Deployment:

  1. Prepare Assets: Optimize images (512x512+ recommended)
  2. Upload to IPFS: Use Pinata, Infura, or local node
  3. Pin Content: Ensure availability across network
  4. Generate Metadata: Reference IPFS hashes in JSON
  5. Test Accessibility: Verify content loads from multiple gateways
  6. Batch Upload: Use scripts for large collections

Popular IPFS Services

Pinata
  • User-friendly dashboard
  • API for automation
  • Reliable pinning service
  • Analytics and insights
Most popular for NFT projects
Infura IPFS
  • Enterprise-grade infrastructure
  • High availability
  • Developer-focused APIs
  • Ethereum ecosystem integration
Best for enterprise projects
Web3.Storage
  • Free tier available
  • Filecoin integration
  • Simple upload API
  • Redundant storage
Good for beginners

Marketplace Optimization Strategies

Optimize your metadata for maximum visibility and engagement across NFT platforms:

Platform-Specific Optimization

  • Trait Filtering: Use consistent trait_type names
  • Rarity Ranking: OpenSea calculates automatically from traits
  • Display Types: Use boost_percentage, boost_number for stats
  • Collection Description: Rich descriptions improve discoverability
  • External Links: Drive traffic to project website

  • Standard Compliance: Follow ERC-721 metadata standards
  • Image Optimization: Square formats (1:1 ratio) work best
  • Animation Support: MP4, GIF, WebM for animated NFTs
  • Metadata Caching: Some platforms cache, plan for updates

SEO and Discoverability

Metadata SEO Best Practices:

  • Descriptive Names: Include keywords naturally in NFT names
  • Rich Descriptions: Tell the story, include lore and context
  • Consistent Naming: Use predictable patterns for series
  • Trait Consistency: Standardize trait names and values
  • External URLs: Link to detailed project information
  • Social Proof: Reference community and achievements

Bulk Generation and Automation Tools

Scale your NFT collection creation with automated metadata generation:

Programmatic Generation Workflow

Python Script Example
import json
import random

# Define trait probabilities
traits = {
    "Background": {
        "Blue": 40,
        "Red": 30,
        "Green": 20,
        "Gold": 10
    },
    "Eyes": {
        "Normal": 60,
        "Glowing": 30,
        "Laser": 10
    }
}

def generate_metadata(token_id):
    attributes = []
    
    for trait_type, options in traits.items():
        # Weighted random selection
        choice = random.choices(
            list(options.keys()),
            weights=list(options.values())
        )[0]
        
        attributes.append({
            "trait_type": trait_type,
            "value": choice
        })
    
    return {
        "name": f"My NFT #{token_id}",
        "description": "Amazing NFT collection",
        "image": f"ipfs://QmHash{token_id}",
        "attributes": attributes
    }

# Generate collection
for i in range(1, 10001):
    metadata = generate_metadata(i)
    with open(f"metadata/{i}.json", "w") as f:
        json.dump(metadata, f, indent=2)

No-Code Generation Tools

GUI Tools
  • HashLips Art Engine: Popular community tool
  • NFT-Generator.io: Online generation platform
  • Bueno Art Generator: All-in-one solution
  • Nift Generator: Simple trait combination
Command Line
  • Custom Scripts: Python, JavaScript, Rust
  • NFT Toolkit: Community-maintained tools
  • Solana CLI Tools: For Solana NFTs
  • Ethereum Scripts: ERC-721/1155 generation

Quality Assurance and Testing

Ensure your NFT metadata meets professional standards before deployment:

Metadata Validation Checklist

Required Validations
  • JSON Syntax: Valid JSON formatting
  • Required Fields: name, description, image present
  • Image URLs: All images accessible
  • Trait Consistency: Standardized trait names
  • Character Limits: OpenSea field limits respected
Quality Checks
  • Rarity Distribution: Verify expected percentages
  • Duplicate Detection: No identical combinations
  • Image Quality: Consistent dimensions and quality
  • Typo Checking: Spell-check all text content
  • Marketplace Preview: Test on testnet first

Success Stories and Case Studies

Anurag
Anurag Sharma
NFT Collection Founder

"This metadata generator helped launch our 10K collection perfectly. The trait system and rarity calculations were spot-on, resulting in 2.5 ETH floor price within a month. The IPFS integration saved us thousands in hosting costs."

Neemesh
Neemesh Yadav
Blockchain Developer

"The bulk generation feature processed our 50K collection metadata in minutes. The OpenSea compatibility and trait hierarchy system created the exact rarity distribution we wanted. Saved weeks of manual work."

NFT Metadata for Solana (Metaplex Standard)

While Ethereum-based guides dominate search results, Solana NFT volume regularly matches or exceeds Ethereum's. The Metaplex metadata standard is structurally different from ERC-721 — and most existing guides don't cover it properly. Here's the correct JSON structure for Solana NFTs in 2026:

{
  "name": "Solana NFT #1",
  "symbol": "SNFT",
  "description": "A Solana-native NFT with Metaplex standard metadata",
  "image": "https://arweave.net/abc123...",
  "external_url": "https://myproject.com",
  "attributes": [
    {
      "trait_type": "Background",
      "value": "Gradient Purple"
    },
    {
      "trait_type": "Rarity",
      "value": "Legendary"
    }
  ],
  "properties": {
    "files": [
      {
        "uri": "https://arweave.net/abc123...",
        "type": "image/png"
      }
    ],
    "category": "image",
    "creators": [
      {
        "address": "9WzDXwBbmPEi3CgRKkR...",
        "share": 100
      }
    ]
  },
  "collection": {
    "name": "My Solana Collection",
    "family": "My Project"
  }
}

Key Differences from ERC-721

Feature ERC-721 (Ethereum) Metaplex (Solana)
Symbol Field Not in metadata (contract-level) Required in metadata JSON
Creators Array Not native Built-in with wallet addresses and share %
Collection Field Handled by contract Explicit collection object in metadata
Properties.files Uses animation_url Explicit files array with URI and MIME type
Preferred Storage IPFS (ipfs:// URIs) Arweave (https://arweave.net/ URIs)
Uses Field Not available Supports consumable/limited-use NFTs
Solana Tip: Metaplex metadata is typically stored on Arweave rather than IPFS. Most Solana tooling (Candy Machine, Sugar CLI) defaults to Arweave uploads. If you're migrating from an Ethereum project, you'll need to restructure your metadata JSON — the properties.creators and properties.files fields are required by Metaplex and have no ERC-721 equivalent.

ERC-1155 Multi-Token Metadata

ERC-1155 is increasingly popular for Web3 games, loyalty programs, and any project that needs both fungible and non-fungible tokens in a single smart contract. Its metadata structure differs from ERC-721 in several important ways:

ERC-1155 URI Pattern

Instead of individual tokenURI() calls like ERC-721, ERC-1155 uses a uri() function with an {id} substitution pattern:

// Contract returns a URI template:
"https://api.myproject.com/metadata/{id}.json"

// For token ID 42, the marketplace replaces {id}:
"https://api.myproject.com/metadata/42.json"

// The {id} must be a 64-character lowercase hex string (padded):
"https://api.myproject.com/metadata/000000000000000000000000000000000000000000000000000000000000002a.json"

Key ERC-1155 Metadata Differences

What's Different

  • Quantities: Tokens can have supply > 1 (semi-fungible)
  • Decimals: Optional decimals field for fungible tokens
  • URI Pattern: Uses {id} substitution in hex format
  • Gas Efficiency: Single contract for entire ecosystem
  • Batch Transfers: Multiple token types in one transaction

Best Use Cases in 2026

  • Gaming: In-game items, currencies, and skins
  • Loyalty Programs: Points + membership NFTs in one contract
  • Event Tickets: Multiple ticket tiers as different token IDs
  • Bundle Sales: Combine fungible and unique tokens
  • DAOs: Governance tokens + membership badges

ERC-6551: Token-Bound Accounts (TBA) Metadata

ERC-6551 is one of the most significant NFT innovations since ERC-721. It allows NFTs to own assets — essentially giving each NFT its own wallet address. This creates entirely new metadata requirements that almost no existing guide covers:

What Token-Bound Accounts Change

With ERC-6551, an NFT can hold other tokens, NFTs, and interact with DeFi protocols. The metadata needs to communicate these capabilities:

{
  "name": "Character #1",
  "description": "An RPG character NFT with its own inventory wallet",
  "image": "ipfs://QmCharacterImage...",
  "attributes": [
    {"trait_type": "Class", "value": "Warrior"},
    {"trait_type": "Level", "value": 15, "display_type": "number"},
    {"trait_type": "Has Token-Bound Account", "value": "Yes"}
  ],
  "tba_capabilities": {
    "can_hold_erc20": true,
    "can_hold_erc721": true,
    "can_hold_erc1155": true,
    "account_address": "0x1234...abcd"
  },
  "external_url": "https://myproject.com/character/1"
}
Why This Matters: In Web3 gaming, a character NFT with ERC-6551 can own its equipment (other NFTs) and in-game currency (ERC-20 tokens). When you sell the character, all owned assets transfer with it. Your metadata should reflect what the TBA holds and what it can do — this information directly affects marketplace valuation and buyer decisions.

2026 ERC-6551 Use Cases

  • Gaming Characters: NFTs that own inventory items, weapons, and in-game currency
  • Profile NFTs: Social identity tokens that own achievements, badges, and reputation tokens
  • Brand Loyalty: Membership NFTs that accumulate reward tokens automatically
  • Investment DAOs: NFT membership that holds the member's share of pooled assets

Making Your Metadata Permanent (Rug-Proof Storage)

After the CloneX incident in April 2025 — where Cloudflare restrictions made the entire RTFKT/Nike CloneX collection's art inaccessible — the question "how do I make my NFT metadata permanent?" became the most critical decision in any project launch. Here's the honest comparison:

Storage Method Permanence Cost Speed Best For
IPFS + Pinning (Pinata/nft.storage) Semi-permanent (requires active pinning) Low ($0-20/month) Fast with gateways Most NFT projects
Arweave Permanent (pay-once, stored forever) One-time fee (~$0.01-0.05 per MB) Moderate High-value collections, Solana NFTs
On-Chain (Smart Contract) Truly immutable (lives on blockchain) Very expensive (gas costs) Instant Small SVG/generative art, critical metadata
Centralized Server (AWS/Cloudflare) Not permanent (can be changed/deleted) Standard hosting costs Fastest Development/testing only
Lesson from CloneX (April 2025): Nike's RTFKT stored CloneX NFT art on Cloudflare-proxied servers. When access restrictions were applied, the entire collection's images became unreachable — holders owned tokens pointing to broken URLs. This affected a collection worth hundreds of millions. Recommendation: Always use IPFS or Arweave for production NFT metadata and images. Use centralized servers only during development.

Recommended Storage Strategy for 2026

  • Images/Media: Upload to Arweave for permanent storage, or IPFS with pinning via Pinata or nft.storage
  • Metadata JSON: Upload to the same decentralized storage as your images — keep them together
  • Critical Metadata: For high-value collections, store essential properties (name, rarity) on-chain as a backup
  • Smart Contract URI: Point to IPFS CID or Arweave transaction ID — never a centralized URL

Marketplace-Specific Metadata Requirements

Each major NFT marketplace has specific requirements for metadata to display correctly. Get any of these wrong and your NFTs will appear broken or incomplete on that platform:

Requirement OpenSea Blur Magic Eden
Required Fields name, image name, image name, image
Image Formats PNG, JPG, GIF, SVG, WebP PNG, JPG, GIF, SVG PNG, JPG, GIF, SVG (+ Solana SPL formats)
Min Image Size Recommended 512×512px No strict minimum Recommended 500×500px
Max File Size 100 MB (images), 100 MB (media) ~50 MB recommended 100 MB (images)
Animation Support MP4, WebM, GIF, GLB, GLTF via animation_url MP4, GIF via animation_url MP4, GIF (varies by chain)
Trait Display Types number, boost_percentage, boost_number, date Inherits from OpenSea standard Standard attributes array
Chains Supported Ethereum, Polygon, Arbitrum, Base, Avalanche, more Ethereum, Blast Solana, Ethereum, Polygon, Bitcoin (Ordinals)
Metadata Caching Cached; use "Refresh Metadata" button Auto-refreshes periodically Cached; use refresh endpoint

Our free NFT Metadata Generator creates JSON files that are compatible with all three marketplaces. The generated metadata follows the OpenSea standard (which Blur also reads) and can be adapted for Magic Eden's Solana requirements.

Batch Collection Metadata Structure

Most NFT creators are generating collections of hundreds or thousands of tokens, not single items. Understanding how batch metadata works with IPFS is essential for a successful launch:

How Numbered JSON Files Work

For a collection of 10,000 NFTs, you create numbered JSON files — each file corresponds to a token ID:

metadata/
├── 0.json      →  Token ID 0 metadata
├── 1.json      →  Token ID 1 metadata
├── 2.json      →  Token ID 2 metadata
├── ...
├── 9999.json   →  Token ID 9999 metadata

IPFS Folder CID and baseURI

When you upload this entire folder to IPFS, you get a single folder CID. Your smart contract's baseURI points to this folder, and each token's full metadata URI is constructed automatically:

// Smart contract baseURI:
"ipfs://QmFolderCID123abc/"

// Token ID 0 resolves to:
"ipfs://QmFolderCID123abc/0.json"

// Token ID 42 resolves to:
"ipfs://QmFolderCID123abc/42.json"

// Marketplace fetches metadata from:
"https://ipfs.io/ipfs/QmFolderCID123abc/42.json"

Batch Generation Best Practices

  • File Naming: Use zero-indexed numbers (0.json, 1.json) matching your token IDs — some contracts start at token ID 0, others at 1
  • Image References: Each metadata JSON should point to the corresponding image: "image": "ipfs://QmImageFolderCID/42.png"
  • Upload Order: Upload images first → get image folder CID → reference in metadata JSONs → upload metadata folder → get metadata folder CID → set as baseURI in contract
  • Validation: Before uploading to IPFS, validate every JSON file locally — one malformed file breaks that token on all marketplaces
  • No-Code Option: Our NFT Metadata Generator handles all of this automatically — define your traits and rarity, and download the complete numbered JSON collection as a ZIP file

Frequently Asked Questions

NFT metadata is the JSON data that describes an NFT's properties — its name, image URL, traits, attributes, and other characteristics. This metadata determines how your NFT appears on marketplaces like OpenSea and Blur, enables trait filtering, affects rarity rankings, and provides searchability for collectors. Without proper metadata, NFTs appear as blank or broken items on platforms.

NFT metadata uses JSON (JavaScript Object Notation) format. The standard includes fields like name, description, image (usually an IPFS URI), external_url, and an attributes array containing trait objects. ERC-721 and ERC-1155 tokens on Ethereum follow the OpenSea metadata standard, while Solana NFTs use the Metaplex metadata standard with different field structures.

Upload your metadata JSON files and images to IPFS using pinning services like Pinata, Infura, or nft.storage. Each file gets a unique content identifier (CID). Reference these CIDs in your metadata using the ipfs:// protocol. For collections, upload the entire metadata folder to get a single folder CID, then reference individual files as ipfs://FolderCID/1.json, ipfs://FolderCID/2.json, etc.

OpenSea requires the name and image fields at minimum. Recommended fields include description, external_url, and the attributes array for trait filtering. Optional fields include animation_url for video/3D content, background_color as a hex string, and youtube_url. Images should be at least 512×512 pixels in PNG, JPG, GIF, SVG, or WebP format.

ERC-721 tokens are unique one-of-one NFTs, each with individual metadata. ERC-1155 supports both fungible and non-fungible tokens in a single contract — metadata uses a {id} substitution pattern in the URI, and tokens can have quantities greater than 1. ERC-1155 also supports the decimals field for semi-fungible tokens and is more gas-efficient for collections.

It depends on your storage method. Metadata on centralized servers can be changed anytime — which is a risk. IPFS content is immutable by hash, but you can update the token URI in a mutable smart contract to point to new metadata. Arweave provides permanent, truly immutable storage. On-chain metadata (stored directly in the smart contract) is the most permanent but also the most expensive option.

Add an attributes array to your metadata JSON. Each attribute object needs trait_type (category name like "Background" or "Eyes") and value (the specific trait like "Blue" or "Laser"). For numeric traits, add display_type as "number", "boost_percentage", or "boost_number". You can also set max_value for progress-bar style display on marketplaces.

On-chain metadata is stored directly in the smart contract on the blockchain — it's permanent and censorship-resistant but expensive (high gas costs). Off-chain metadata is stored externally on IPFS, Arweave, or centralized servers, with only a URI reference on-chain. Most NFT projects use off-chain storage via IPFS or Arweave for cost efficiency while maintaining decentralization.

Related Articles

Cryptocurrency Tools Guide

Explore essential crypto and blockchain development tools for modern projects.

Read More
Smart Contract Formatter Guide

Learn Solidity code formatting and best practices for smart contract development.

Read More

Related Crypto Tools

NFT Metadata Generator

Generate marketplace-ready NFT metadata JSON files for single tokens or entire collections up to 10,000+ NFTs. Free, no sign-up required.

Gas Fee Calculator

Estimate Ethereum gas fees for NFT minting, transfers, and smart contract interactions in real-time.

Smart Contract Formatter

Format and beautify Solidity code for ERC-721, ERC-1155, and other smart contracts with proper indentation.

Crypto Wallet Validator

Validate Ethereum, Solana, Bitcoin, and other blockchain wallet addresses before sending transactions.