Um arquivo de save costuma ser opaco exatamente quando você mais precisa dele, então este visualizador reconhece as famílias que os jogos reais usam e mostra o que cada especificação expõe. O NBT da família Minecraft é analisado tag a tag conforme a especificação do wiki.vg (os 12 tipos de tag, invólucros gzip/zlib/raw — level.dat é gzip, servers.dat raw). Saves da Unreal Engine são identificados pela magia "GVAS" e decodificados conforme o layout uesave/gvas: versão do save, versões de pacote UE4 e UE5, a tupla FEngineVersion com o branch e a tabela de versões personalizadas; saves de Palworld da Steam são desembrulhados pelo seu contêiner real (dois ints de cabeçalho, magia "PlZ1", fluxo zlib) até a carga GVAS. Saves em SQLite são abertos apenas-leitura via node:sqlite e listados tabela por tabela com contagens e linhas de prévia. Saves de texto são detectados estruturalmente: JSON (estilo deck-builder), XML (um SaveGame de Stardew Valley é reconhecido pelos campos raiz documentados), INI (incluindo configuração [/Script/…] da Unreal) e tabelas Lua (família Hades). Contêineres Zip são relatados com suas entradas internas. Todo o resto recai numa leitura de entropia de Shannon, um dump hexadecimal dos primeiros 256 bytes e uma varredura de strings imprimíveis, com heurística para .sav da engine Source — seus tokens de blocos (ADVSYS, EntityPatch, Response System…) estão documentados na Valve Developer Community. Campos relevantes de progresso (name, level, gold, health, seed, playtime…) vão para um painel de fatos-chave, e cada análise é limitada — orçamento de nós, teto de profundidade, prévias de arrays — porque saves são entrada não confiável. Onde vivem os saves? Jogos com Steam Cloud os guardam em Steam/userdata///remote (conforme a documentação do Steamworks); os demais, onde o jogo quiser. Esta ferramenta nunca modifica o seu arquivo — lê uma cópia na memória e apenas renderiza.