1# Overview 2 3FlatBuffers is an efficient cross platform serialization library for C++, C#, C, 4Go, Java, Kotlin, JavaScript, Lobster, Lua, TypeScript, PHP, Python, Rust and 5Swift. It was originally created at Google for game development and other 6performance-critical applications. 7 8It is available as Open Source on 9[GitHub](https://github.com/google/flatbuffers) under the Apache license v2.0. 10 11## Why Use FlatBuffers? 12 13<div class="grid cards" markdown> 14 15- :material-clock-fast:{ .lg .middle } **Access to serialized data without 16 parsing/unpacking** 17 18 --- 19 Access the data directly without unpacking or parsing. 20 21- :material-memory:{ .lg .middle } **Memory Efficiency and Speed** 22 23 --- 24 The only memory needed to access your data is that of the buffer. No heap is 25 required. 26 27- :material-compare-horizontal:{ .lg .middle } **Backwards and Forwards 28 Compatibility** 29 30 --- 31 The only memory needed to access your data is that of the buffer. No heap is 32 required. 33 34- :material-scale-off:{ .lg .middle } **Small Footprint** 35 36 --- 37 Minimal dependencies and small code footprint. 38 39</div> 40 41## Why not use... 42 43=== "Protocol Buffers" 44 45 Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary 46 difference being that FlatBuffers does not need a parsing/unpacking step to a 47 secondary representation before you can access data, often coupled with 48 per-object memory allocation. The code is an order of magnitude bigger, too. 49 50=== "JSON" 51 52 JSON is very readable (which is why we use it as our optional text format) and 53 very convenient when used together with dynamically typed languages (such as 54 JavaScript). When serializing data from statically typed languages, however, 55 JSON not only has the obvious drawback of runtime inefficiency, but also forces 56 you to write more code to access data (counterintuitively) due to its 57 dynamic-typing serialization system. In this context, it is only a better choice 58 for systems that have very little to no information ahead of time about what 59 data needs to be stored. 60