# Serialization
If you only need to record and replay changes within the browser locally, then we can simply save the current view by deep copying the DOM object. For example, the following code implementation (simplified example with jQuery, saves only the body part):
```javascript
// record
const snapshot = $('body').clone();
// replay
$('body').replaceWith(snapshot);
```
We now implemented a snapshot by saving the whole DOM object in memory.
But the object itself is not **serializable**, meaning we can't save it to a specific text format (such as JSON) for transmission. We need that to do remote recording, and thus we need to implement a method for serializing the DOM data.
We do not use an existing open source solutions such as [parse5](https://github.com/inikulin/parse5) for two reasons:
1. We need to implement a "non-standard" serialization method, which will be discussed in detail below.
2. This part of the code needs to run on the recorded page, and we want to control the amount of code as much as possible, only retaining the necessary functions.
## Special handling in serialization
The reason why our serialization method is non-standard is because we still need to do the following parts:
1. Output needs to be descriptive. All JavaScript in the original recorded page should not be executed on replay. In rrweb we do this by replacing `script` tags with placeholder `noscript` tags in snapshots. The content inside the script is no longer important. We instead record any changes to the DOM that scripts cause, and we do not need to fully record large amounts of script content that may be present on the original web page.
2. Recording view state that is not reflected in the HTML. For example, the value of `` will not be reflected in its HTML, but will be recorded by the `value` attribute. We need to read the value and store it as a property when serializing. So it will look like ``.
3. Relative paths are converted to absolute paths. During replay, we will place the recorded page in an `