Write for Us

Share Your C++ and JSON Development Expertise

Do you have practical experience with modern C++, JSON data handling, API integration, serialization, build systems, or open-source development?

nlohmannjson.com welcomes original contributions from C++ developers, software engineers, technical writers, library maintainers, educators, DevOps professionals, embedded developers, and open-source contributors.

We publish clear, technically accurate content that helps developers use JSON effectively in C++ projects. From beginner-friendly parsing tutorials to advanced serialization, performance, binary formats, and production integration, every article should solve a meaningful development problem.

Why contribute to nlohmannjson.com?

Writing for nlohmannjson.com allows you to share practical knowledge with developers working on applications, APIs, embedded systems, games, command-line tools, backend services, and enterprise software.

As a contributor, you can:

• Demonstrate your C++ development expertise
• Share tested code and implementation patterns
• Help developers avoid common JSON mistakes
• Explain complex library features clearly
• Contribute to the open-source developer community
• Build your professional authority
• Showcase your technical writing skills
• Reach readers interested in modern C++ development

We value practical experience, accurate explanations, complete examples, and honest discussion of technical trade-offs.

Topics We Accept

We accept original articles related to nlohmann/json, C++, JSON standards, software integration, development tools, testing, performance, and troubleshooting.

nlohmann/json Beginner Guides

We welcome beginner-friendly articles covering:

• What nlohmann/json is
• How JSON works in C++
• Installing the library
• Including json.hpp
• Creating JSON objects
• Parsing JSON strings
• Reading JSON from files
• Writing JSON to files
• Accessing object values
• Working with JSON arrays
• Checking value types
• Formatting JSON output
• Handling basic parsing errors

Beginner guides should explain important terminology and avoid assuming that every reader already understands modern C++ syntax.

Installation and Project Setup

Contributors may submit practical setup guides for different development environments.

Suitable topics include:

• Installing nlohmann/json with vcpkg
• Installing the library with Conan
• Using the single-header version
• Adding the library through CMake
• Using FetchContent
• Adding the project as a Git submodule
• Integrating the library into Visual Studio
• Setting up GCC or Clang projects
• Using the library on Windows
• Using the library on Linux
• Using the library on macOS
• Troubleshooting missing-header errors

Installation tutorials should mention the tested library version, compiler, operating system, C++ standard, and build-system version.

JSON Parsing

We accept detailed guides about parsing JSON data.

Possible topics include:

• Parsing JSON strings
• Parsing files and streams
• Parsing API responses
• Working with invalid JSON
• Handling comments
• Ignoring comments during parsing
• Parsing partial input
• Understanding parse callbacks
• Handling UTF-8 input
• Working with large JSON files
• Checking accepted input before parsing
• Using exception and non-exception parsing modes

Articles should explain the expected input, parsing method, possible errors, and validation approach.

Creating and Modifying JSON

Writers may contribute guides about building and changing JSON values.

Topics may include:

• Creating JSON objects with initializer lists
• Adding new keys
• Updating existing values
• Removing keys
• Appending array values
• Creating nested objects
• Merging JSON objects
• Copying values
• Moving JSON data
• Checking whether a key exists
• Using contains()
• Using find()
• Working with default values

Code examples should show both the implementation and the expected JSON output.

Serialization and Deserialization

We welcome practical articles about converting between C++ values and JSON.

Relevant topics include:

• Serializing C++ objects
• Deserializing JSON into objects
• Using to_json
• Using from_json
• Working with NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE
• Working with intrusive macros
• Serializing nested classes
• Handling optional fields
• Working with default values
• Supporting non-default-constructible types
• Managing enums
• Serializing inheritance structures
• Handling versioned data models

Articles should explain the trade-offs between macros, manual converters, and custom serializers.

STL Container Integration

Contributors may write about converting standard-library containers.

Suitable subjects include:

• Using std::vector
• Serializing std::map
• Working with std::unordered_map
• Converting std::list
• Using std::set
• Handling std::array
• Serializing pairs and tuples
• Working with std::optional
• Managing nested containers
• Handling custom allocators
• Avoiding unexpected array or object conversions

Examples should clearly identify the C++ standard required for each feature.

Custom Data Types

We accept advanced tutorials about integrating application-specific types.

Potential topics include:

• Writing custom serializers
• Using argument-dependent lookup
• Specializing adl_serializer
• Supporting third-party types
• Serializing private members
• Handling immutable data structures
• Supporting strong typedefs
• Working with date and time types
• Serializing filesystem paths
• Converting mathematical structures
• Managing polymorphic data
• Validating custom types during deserialization

Advanced articles should explain why a particular approach is appropriate and identify any limitations.

JSON Pointer

Writers may submit articles about RFC 6901 JSON Pointer support.

Topics may include:

• Understanding JSON Pointer syntax
• Accessing nested values
• Creating pointers dynamically
• Escaping special characters
• Using checked and unchecked access
• Creating missing paths
• Handling invalid pointers
• Comparing JSON Pointer with object traversal
• Using pointers in configuration systems
• Building reusable data-access utilities

Examples should clearly show the original JSON, the pointer expression, and the resulting value.

JSON Patch and Merge Patch

We welcome practical guides related to JSON Patch and JSON Merge Patch.

Possible subjects include:

• Understanding RFC 6902 JSON Patch
• Creating patch operations
• Applying add, remove, and replace operations
• Using move, copy, and test operations
• Generating differences between JSON documents
• Understanding RFC 7386 Merge Patch
• Comparing JSON Patch and Merge Patch
• Updating configuration documents
• Handling patch failures
• Validating patch operations
• Building API update workflows

Articles should explain when each patching method is appropriate and how to handle untrusted patch data safely.

Binary Formats

Contributors may write about supported binary serialization formats.

Relevant topics include:

• Converting JSON to CBOR
• Working with MessagePack
• Using BSON
• Working with UBJSON
• Using BJData
• Comparing binary JSON formats
• Reading binary values
• Writing binary output
• Handling endianness
• Measuring serialized size
• Choosing a format for network communication
• Troubleshooting invalid binary data

Comparison articles should include clearly documented test conditions rather than unsupported performance claims.

API Integration

We accept articles about using JSON in web services and API clients.

Potential topics include:

• Parsing REST API responses
• Creating JSON request bodies
• Integrating with libcurl
• Handling HTTP errors
• Validating API data
• Managing missing fields
• Working with paginated responses
• Parsing authentication responses
• Building reusable API models
• Handling schema changes
• Logging API payloads safely
• Avoiding exposure of sensitive values

Remove real API keys, access tokens, customer records, and private endpoints from all examples.

Configuration Files

Writers may contribute tutorials about JSON-based application configuration.

Suitable topics include:

• Loading configuration files
• Applying default settings
• Validating configuration values
• Supporting optional fields
• Merging environment-specific settings
• Saving application preferences
• Detecting malformed files
• Recovering from missing configuration
• Managing configuration versions
• Using JSON Pointer for settings
• Protecting secrets
• Creating human-readable configuration output

Security-sensitive values should not be stored in plain-text examples unless the article clearly explains the associated risks.

Error Handling and Exceptions

We welcome detailed articles about safe failure handling.

Topics may include:

• Understanding parse errors
• Handling type errors
• Handling out-of-range errors
• Understanding invalid iterators
• Catching library exceptions
• Disabling exceptions
• Using error codes or alternative flows
• Logging JSON failures
• Returning useful error messages
• Preserving application stability
• Testing malformed input
• Avoiding silent data corruption

Articles should avoid catching every exception without explaining how the application should respond.

Iterators and Traversal

Contributors may write about navigating JSON data efficiently.

Possible topics include:

• Iterating over arrays
• Iterating over objects
• Accessing keys and values
• Using structured bindings
• Recursive traversal
• Flattening JSON
• Unflattening JSON
• Searching nested structures
• Modifying values during iteration
• Avoiding invalid iterators
• Building reusable visitor functions
• Traversing unknown schemas

Code should clearly distinguish object iteration from array iteration.

SAX Parsing

We accept advanced articles about the SAX interface.

Suitable subjects include:

• Understanding DOM and SAX parsing
• Implementing a SAX handler
• Processing large JSON streams
• Reducing memory usage
• Validating values during parsing
• Stopping parsing early
• Handling parse events
• Building streaming importers
• Comparing SAX performance with DOM parsing
• Troubleshooting callback behavior

Performance discussions should include the dataset size, compiler, build flags, hardware, and library version.

Performance and Memory Usage

Writers may submit well-tested performance articles.

Potential topics include:

• Reducing unnecessary JSON copies
• Using move semantics
• Reserving container capacity
• Parsing large documents
• Choosing between DOM and SAX
• Measuring memory usage
• Comparing parsing approaches
• Optimizing serialization
• Avoiding repeated conversions
• Profiling JSON-heavy applications
• Managing deeply nested data
• Understanding header-only build impact

Do not claim that one approach is universally fastest without providing reproducible benchmarks.

CMake Integration

We welcome articles about modern CMake workflows.

Topics may include:

• Using find_package
• Linking nlohmann_json::nlohmann_json
• Adding the library with FetchContent
• Using an embedded dependency
• Exporting project targets
• Supporting installable applications
• Managing versions
• Creating reproducible builds
• Using presets
• Troubleshooting target-not-found errors
• Handling cross-compilation
• Integrating with CI pipelines

CMake examples should use valid, modern syntax and identify the minimum required version.

Package Managers

Contributors may write about dependency-management workflows.

Suitable topics include:

• Installing with vcpkg
• Managing versions through Conan
• Using package locks
• Supporting offline builds
• Creating reproducible environments
• Handling transitive dependencies
• Troubleshooting package discovery
• Managing custom registries
• Updating library versions safely
• Comparing package managers
• Packaging internal C++ projects

Articles should distinguish official project releases from third-party package maintenance.

Compiler Compatibility

We accept content about compiler and language-standard support.

Possible subjects include:

• Using the library with GCC
• Using Clang
• Building with MSVC
• Working with Apple Clang
• Choosing a C++ standard
• Understanding compiler diagnostics
• Resolving template errors
• Fixing standard-library compatibility issues
• Cross-compiling for embedded systems
• Using the library with CI build matrices
• Supporting older toolchains
• Migrating to newer C++ standards

Mention exact compiler versions and build flags when discussing compatibility.

Testing JSON Code

Writers may contribute articles about testing JSON-related functionality.

Topics may include:

• Writing unit tests for serializers
• Testing malformed input
• Verifying optional fields
• Testing schema migrations
• Using Catch2
• Using GoogleTest
• Creating fixture JSON files
• Testing round-trip serialization
• Fuzz-testing parsers
• Testing patch operations
• Checking backward compatibility
• Building regression tests

Do not include confidential production data in test fixtures.

Security and Untrusted JSON

We welcome defensive security content related to parsing and validating data.

Suitable topics include:

• Handling untrusted JSON input
• Limiting payload sizes
• Detecting excessive nesting
• Preventing denial-of-service conditions
• Validating expected types
• Rejecting unknown fields
• Protecting logs from sensitive data
• Avoiding unsafe assumptions
• Fuzz-testing JSON parsers
• Securing API integrations
• Managing configuration secrets
• Safely reporting parse errors

Security content must focus on protection, authorized testing, detection, and remediation.

Embedded and Resource-Constrained Systems

Contributors may write about using JSON in embedded environments.

Potential topics include:

• Evaluating memory requirements
• Cross-compiling the library
• Reducing binary size
• Managing limited heap space
• Processing small configuration files
• Avoiding unnecessary allocations
• Using custom allocators
• Handling serial communication
• Choosing JSON versus binary formats
• Testing on embedded Linux
• Working with microcontroller gateways

Articles should clearly identify the tested hardware, operating system, compiler, and resource constraints.

Game and Application Development

We accept practical content about JSON use in software products.

Topics may include:

• Loading game configuration
• Managing localization files
• Saving player settings
• Defining application themes
• Parsing asset metadata
• Managing plugin manifests
• Building mod configuration systems
• Handling network messages
• Creating data-driven systems
• Updating stored data formats
• Protecting save-file integrity
• Testing configuration migrations

Do not include proprietary game assets, confidential source code, or private company data without permission.

Comparisons with Other JSON Libraries

We welcome balanced and technically accurate comparisons.

A comparison may evaluate:

• nlohmann/json
• RapidJSON
• simdjson
• Boost.JSON
• jsoncpp
• Jsoncons
• Other legitimate C++ JSON libraries

Useful comparison factors include:

• Ease of use
• Parsing performance
• Memory usage
• API design
• Serialization support
• Binary-format support
• Compiler requirements
• Build integration
• Error handling
• Suitable use cases
• Advantages and limitations

Benchmarks should be reproducible and should not be designed to unfairly favor one library.

Troubleshooting and Error Fixes

Detailed troubleshooting guides are especially valuable.

You may write about issues such as:

• nlohmann/json.hpp not found
• Undefined reference errors
• CMake package discovery failures
• Ambiguous conversion errors
• Template-specialization problems
• Parse errors
• Type mismatch errors
• Out-of-range exceptions
• Invalid iterator errors
• Serialization failures
• Unexpected null values
• Unicode or encoding issues
• Compiler errors after an upgrade
• Package-manager version conflicts
• Performance problems with large files

A strong troubleshooting article should include:

• The exact error message
• A minimal reproducible example
• Compiler and library versions
• Build-system information
• Likely causes
• Tested solutions
• Validation steps
• Any limitations of the fix

Do not present an untested suggestion as a guaranteed solution.

Contributor Guidelines

Submit Original Content

Every article must be original and unpublished.

We do not accept:

• Plagiarized articles
• Copied documentation
• Scraped content
• Spun or lightly rewritten tutorials
• Previously published submissions
• Duplicate guest posts
• Poorly reviewed automated content
• Large sections copied from repositories

Submissions may be checked for originality before publication.

Use Accurate and Tested Code

All code examples should be tested before submission.

When relevant, include:

• nlohmann/json version
• C++ standard
• Compiler and version
• Operating system
• Build-system version
• Package-manager version
• Required dependencies
• Expected output
• Exact error message

Never invent compiler output, benchmarks, library behavior, APIs, or compatibility results.

Provide Complete Examples

Code should be complete enough for readers to understand and reproduce.

A good example should explain:

• Required headers
• Relevant namespace aliases
• Input data
• Main operation
• Expected result
• Error-handling approach
• Compilation requirements

Avoid posting isolated code fragments without enough surrounding context.

Keep Code Secure

Remove all sensitive information from examples, including:

• API keys
• Access tokens
• Passwords
• Private URLs
• Customer records
• Internal server names
• Personal information
• Proprietary source code
• Signing keys
• Authentication headers

Use clearly marked placeholder values where necessary.

Write Clearly

Use professional and accessible English.

Explain advanced terminology and divide complex processes into logical sections. Keep paragraphs short and use numbered steps for setup and troubleshooting procedures.

Avoid unnecessary filler, repetitive explanations, unsupported claims, and excessive jargon.

Recommended Article Length

Most guest articles should contain between 1,200 and 2,500 words.

In-depth tutorials, performance studies, and advanced implementation guides may be longer when the additional detail genuinely helps readers.

Technical accuracy and usefulness are more important than word count.

Recommended Article Structure

A complete submission should normally include:

• A clear technical title
• A brief introduction
• Prerequisites
• Relevant H2 and H3 headings
• Tested code examples
• Expected output
• Error-handling notes
• Compatibility information
• Security considerations
• A practical conclusion
• A short author biography

Troubleshooting articles should include a concise explanation of the likely cause and fix near the beginning.

Benchmark Guidelines

Performance articles must use transparent and reproducible testing methods.

Please include:

• Hardware specifications
• Operating system
• Compiler and version
• Optimization flags
• Library versions
• Dataset descriptions
• Number of test iterations
• Measurement method
• Complete benchmark code
• Important limitations

Do not manipulate benchmarks, remove unfavorable results, or present a small synthetic test as proof of universal production performance.

Open-Source and Licensing Guidelines

nlohmann/json is an open-source project distributed under the MIT License.

Contributors must:

• Credit the original project and maintainers
• Respect license requirements
• Preserve required copyright notices
• Identify modified code
• Link to original sources when appropriate
• Avoid presenting third-party code as original work
• Follow licenses for all included examples and assets

Do not submit proprietary code, leaked source code, or material you do not have permission to publish.

Independent Website Disclosure

nlohmannjson.com is an independent informational and educational website.

Contributors must not describe the website as:

• The official nlohmann/json project website
• The official website of Niels Lohmann
• An authorized representative of the project
• The original creator or maintainer of the library
• An official C++ standards resource

Articles should clearly distinguish independent educational content from official project documentation.

Screenshots, Diagrams and Terminal Output

Original screenshots, architecture diagrams, editor images, and terminal examples can make technical articles easier to understand.

Submitted media should be:

• Clear and relevant
• Created by you or licensed for reuse
• Free from sensitive information
• Properly credited when required
• Readable on desktop and mobile devices

Before submitting visuals, remove:

• Personal file paths
• Usernames
• Email addresses
• Access tokens
• Private repository names
• Internal domains
• Customer information
• API credentials
• Proprietary project details

Do not copy diagrams or screenshots from another website without permission.

Linking Policy

Relevant links may be included when they support a technical claim, credit a developer, or direct readers to primary documentation.

Preferred destinations include:

• Official project documentation
• Original GitHub repositories
• C++ standard references
• Compiler documentation
• Package-manager documentation
• Published technical standards
• Original research
• Maintainer-controlled release pages

A contributor may request a relevant link to a:

• Personal website
• Technical portfolio
• GitHub profile
• Open-source project
• Company website
• Professional profile

Every link is reviewed before publication.

We may remove links that are:

• Unrelated
• Excessively promotional
• Misleading
• Keyword-stuffed
• Unsafe
• Low quality
• Added mainly to manipulate search rankings
• Connected to unauthorized or harmful content

Submitting an article does not guarantee backlink approval.

Content We Do Not Accept

nlohmannjson.com does not publish:

• Plagiarized articles
• Previously published submissions
• Copied official documentation
• Fabricated code examples
• Fake compiler output
• Invented benchmarks
• Exposed credentials
• Proprietary source code without permission
• Malicious code
• Unauthorized access tutorials
• Misleading technical claims
• Articles written only for backlinks
• Excessively promotional content
• Irrelevant programming articles
• Content falsely presented as official

Sponsored Posts and Partnerships

We may consider relevant sponsored tutorials, developer-tool reviews, C++ training resources, cloud services, IDE comparisons, package-management tools, and software-development partnerships.

Sponsored content must remain:

• Technically accurate
• Clearly disclosed
• Useful to developers
• Relevant to C++ or JSON development
• Security-conscious
• Compliant with our editorial standards

A commercial proposal should include:

• Your full name
• Company or project name
• Website address
• Proposed topic
• Product or service details
• Intended audience
• Requested link
• Content requirements
• Preferred publication date

Each proposal is reviewed individually.

How to Submit Your Article

Send your topic proposal, detailed outline, or completed draft to our editorial team.

Please include:

• Proposed article title
• Short article summary
• Complete draft or outline
• Target keyword, when relevant
• Author’s full name
• Short author biography
• Website or professional profile
• GitHub or open-source profile
• Previous technical writing samples
• Requested backlink details
• Tested code examples
• Compiler and version information

Google Docs is preferred for the article text. Code may also be provided through a public GitHub Gist or repository when appropriate.

Make sure all links and document permissions allow our editorial team to review the submission.

Contact Details

Email: cloudcorex4@gmail.com

Phone: +971 55 912 8238

Use this subject line for guest-post submissions:

Guest Post Submission – nlohmannjson.com

For sponsored-content proposals, use:

Sponsored Post Inquiry – nlohmannjson.com

Editorial Review Process

Every submission is reviewed for originality, technical accuracy, code quality, readability, security, licensing compliance, and practical value.

Our editorial team may:

• Correct grammar and spelling
• Improve titles and headings
• Restructure unclear sections
• Test code examples
• Request a minimal reproducible example
• Add internal links
• Remove unsuitable external links
• Add security or compatibility notices
• Request benchmark details
• Ask for revisions
• Reject the submission
• Update published content later

Submitting an article does not guarantee publication.

Become a nlohmannjson.com Contributor

Have a useful JSON parsing tutorial, serialization guide, CMake workflow, API integration example, performance study, or tested troubleshooting solution?

Send your proposal or completed article to cloudcorex4@gmail.com.

Use “Guest Post Submission – nlohmannjson.com” as the email subject line.

We look forward to reviewing your contribution.