Privacy Policy & Zero-Upload Execution Guarantee

1. Zero-Upload Local .gguf & config.json Inspection

When you select or drag a .gguf checkpoint or config.json into the GGUF Inspector, the browser reads only the local leading byte slice via File.slice() and DataView in volatile tab memory. Zero bytes of your weights, custom fine-tune names, or serving manifests are ever transmitted over the network.

The GGUF binary container stores all model metadata immediately after the 4-byte ASCII magic ("GGUF" / 0x46554747), 32-bit version integer, 64-bit tensor count, and 64-bit KV pair count—well ahead of multi-gigabyte quantized tensor blocks. By slicing only the first 16 MiB with the browser File API, VRAMLab decodes UTF-8 keys, typed scalars, and tokenizer array lengths without reading tensor payloads.

For FP16, BF16, FP8, or AWQ checkpoints distributed as safetensors shards, dropping the accompanying config.json extracts hidden_size, num_hidden_layers, num_key_value_heads, kv_lora_rank, n_routed_experts, and sliding_window_pattern so you can size vLLM or SGLang clusters before downloading hundreds of gigabytes of weights.

2. Static Edge Delivery & Local Storage Controls

All pages on vram.codeap.com are served as static assets with strict Cross-Origin-Resource-Policy: same-origin and frame-ancestors 'none' headers. Optional theme and language preferences are stored locally via codeap_color_scheme and codeap_lang, alongside aggregate page-view telemetry via Google Tag Manager (GTM-N64WPS2P) that never captures tool inputs.