# Overview

FlatBuffers is an efficient cross platform serialization library for C++, C#, C,
Go, Java, Kotlin, JavaScript, Lobster, Lua, TypeScript, PHP, Python, Rust and
Swift. It was originally created at Google for game development and other
performance-critical applications.

It is available as Open Source on
[GitHub](https://github.com/google/flatbuffers) under the Apache license v2.0.

## Why Use FlatBuffers?

<div class="grid cards" markdown>

- :material-clock-fast:{ .lg .middle } **Access to serialized data without
  parsing/unpacking**

    ---
    Access the data directly without unpacking or parsing.

- :material-memory:{ .lg .middle } **Memory Efficiency and Speed**

    ---
    The only memory needed to access your data is that of the buffer.
  No heap is required.

- :material-compare-horizontal:{ .lg .middle } **Backwards and Forwards
  Compatibility**

    ---
    FlatBuffers enables the schema to evolve over time while still maintaining
  forwards and backwards compatibility with old flatbuffers.

- :material-scale-off:{ .lg .middle } **Small Footprint**

    ---
    Minimal dependencies and small code footprint.

</div>

## Why not use...

=== "Protocol Buffers"

    Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary
    difference being that FlatBuffers does not need a parsing/unpacking step to a
    secondary representation before you can access data, often coupled with
    per-object memory allocation. The code is an order of magnitude bigger, too.

=== "JSON"

    JSON is very readable (which is why we use it as our optional text format) and
    very convenient when used together with dynamically typed languages (such as
    JavaScript). When serializing data from statically typed languages, however,
    JSON not only has the obvious drawback of runtime inefficiency, but also forces
    you to write more code to access data (counterintuitively) due to its
    dynamic-typing serialization system. In this context, it is only a better choice
    for systems that have very little to no information ahead of time about what
    data needs to be stored.